[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