[Openembedded-architecture] layers.openembedded.org - suggestion to remove obsolete layers

Mark Hatle mark.hatle at kernel.crashing.org
Wed Dec 4 14:20:56 UTC 2019



On 12/4/19 7:09 AM, Tom Rini wrote:
> On Sun, Dec 01, 2019 at 03:47:43PM -0600, Mark Hatle wrote:
> 
>> I've been looking through the layer index (master primarly), and I think we need
>> to figure out a policy of when to remove a layer from master indexing.
>>
>> So I'd like to suggest the following policy:
>>
>> - For released branches, we do not remove layers from the index unless the layer
>> URL is no longer valid.  If it is not valid for more then 90 days, we should
>> remove it.
>>
>> - For master branch, we use a series of tests to determine if the layer is still
>> actively maintained and useful to users:
>>
>>    1. Is the layer URL valid?  If it has not been valid for more then 90 days,
>> it should be removed.
>>
>>    2. Does the layer claim to support any of the last three releases: the
>> current (or planned release) or prior two releases?
>>       i.e. LAYERSERIES_COMPAT does not have thud, warrior or zeus in it.
>>
>>       This means the layer has not been updated within the last 18 months, and
>> should be removed.
>>
>>
>> So why the suggestion above?
>>
>> The URL one should be obvious, if the layer can no longer be downloaded then it
>> should be removed.  We should be able to detect when the index hasn't been
>> updated in 90 days.  (We could consider dropping this to 45 or even 30 days.)
>>
>> Looking for the last 3 releases give people the opportunity to update their
>> layers, or other people to find layers that may be of interest to them and
>> submit updates.  After 18 months, the layer is clearly no longer being
>> maintained and will cause more confusion then actually helping people find
>> something useful.  (Also after 18 months of inactivity, there is a much higher
>> likelihood of security vulnerabilities in the code.)
>>
>>
>> So if the TSC agrees that this is a good proposal, I can work with Paul to
>> implement it (most likely manually at first, and then eventually via automation.)
> 
> My concerns here are:
> - There's a lot of non-public projects out there not on "last 3" and
>   having older information is still useful.

I'm not suggesting removing layers from release branch indexes (unless the URL
is no longer valid.)  It would primarily be removing it from master index.  (It
does leave a gap that if it suddenly starts being worked on again, how do we
know.  This could be accomplished using the same criteria in reverse, it claims
compatibility and has been updated within 18 months (or so)..

> - As was already stated (but on my mind right now as I hop over to see
>   if anyone made recipes for X/Y/Z) being able to answer the question
>   of "a long time ago someone made a recipe for X" is useful.
> 
> So I would ask for more visual indicators that something is old rather
> than removing old things.

The problem I have is that if I use bitbake-layers layerindex-fetch <layer> it
can and will fetch a pile of garbage (non-maintained, non-functional layers) now
that will screw up my project.  I don't want any chance of obsolete code ending
up in my development projects as I work on things.  It diminishes the value of
the layer index beyond someone just connecting and reading the output.

--Mark


More information about the Openembedded-architecture mailing list