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

Mark Hatle mark.hatle at kernel.crashing.org
Mon Dec 2 14:46:00 UTC 2019



On 12/2/19 8:30 AM, Martin Jansa wrote:
> Even if the original URL isn't available anymore there might be some existing
> forks on github or elsewhere.

But how would someone find it, and if they did find a fork how would they know
it's 'authentic', i.e. not maliciously tampered with?

It's one thing if someone forks it and maintains it, I'd hope/expect in that
case they would try to take ownership on the layerindex.  (This has certainly
happened in the past.)

> When searching for strange recipes, even finding the name of the layer where it
> was before is sometimes useful to find it somewhere else - so I would prefer to
> still be able to find it in the index even with clear warning that the original
> repo is gone or seems unmaintained by some rules.
> 
> I agree that including whole unmaintained layer to build from master or latest
> release is often problematic, but many projects are still using old releases
> (this might happen even more often when LTS is available) where it still might
> work fine even with last commit in pyro branch 2 years ago and importing just a
> few recipes from even older less maintained layer is still generally easy and
> useful starting point to start maintaining them somewhere else.

As long as the URL is valid, I would not ever suggest removing a layer from a
released branch.  Updating (or not) doesn't matter as the layer itself claims to
be compatible with that release branch.

> If some layer is actively used in project based on e.g. pyro, then I understand
> that maintainer might be updating only pyro and if nobody steps in to maintain
> (and more importantly use and test the layer in project using newer release),
> then it looks unmaintained, but still useful for some people (and IMHO should be
> discoverable on the index).

Yes, I'm only saying it is removed from master, not all of the index.

In the current layer index version there is a switch.  One is simply to stop
indexing a particular layer.  This is not what I am suggesting.

Instead what we could do is stop indexing/publishing new layer branches when the
LAYERCOMPAT doesn't match oe-core.

This would allow a layer that still exists but is no longer functional to be
disabled from master.. but if master and/or a new release branch is created it
can validate and then publish.  (Once published it wouldn't be 'unpublished'
from a release branch.  Also it wouldn't be unpublished/removed from master
unless the suggested policy happens, i.e. URL goes away or it hasn't been
updated in in 3 releases.)

--Mark

> On Mon, Dec 2, 2019 at 12:44 AM Mark Hatle <mark.hatle at kernel.crashing.org
> <mailto:mark.hatle at kernel.crashing.org>> wrote:
> 
> 
> 
>     On 12/1/19 5:20 PM, Rich Persaud wrote:
>     >> On Dec 1, 2019, at 16:47, Mark Hatle <mark.hatle at kernel.crashing.org
>     <mailto:mark.hatle at kernel.crashing.org>> 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.
>     >
>     > How about 90 days after a release date which crosses the threshold, or 90
>     days after a 1 week grace period for migration of the site hosting the
>     layer?  That would give the maintainer a consistent 90-day notice for the
>     two conditions which could trigger moving the layer to an "unmaintained"
>     state. 
> 
>     If the URL is not valid, then nobody can use it.  The maintainer could be
>     notified, and the URL updated if it's moved.  If it has just been removed, then
>     it is useless to index it.
> 
>     > As Adrian said, unmaintained layers could be later adopted or forked by a
>     new maintainer.  We may also want to archive layers for the historical
>     record, e.g. at the time they are added to the index and/or periodically.
> 
>     Current layer index I don't think there is any way to do this.  As long as the
>     URL is valid, this is possible -- but it would require us to have a way to list
>     obsolete layers without impacting layerindex users.  (Users include those who
>     connect via web browsers, and tooling, such as bitbake-layers.)
> 
>     --Mark
> 
>     > Rich
>     >
>     _______________________________________________
>     Openembedded-architecture mailing list
>     Openembedded-architecture at lists.openembedded.org
>     <mailto:Openembedded-architecture at lists.openembedded.org>
>     http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
> 


More information about the Openembedded-architecture mailing list