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

Martin Jansa martin.jansa at gmail.com
Mon Dec 2 14:30:32 UTC 2019


Even if the original URL isn't available anymore there might be some
existing forks on github or elsewhere.

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.

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).

On Mon, Dec 2, 2019 at 12:44 AM Mark Hatle <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>
> 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
> http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/tsc/attachments/20191202/dba3d01d/attachment.html>


More information about the tsc mailing list