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 <[email protected]> wrote: > > > On 12/1/19 5:20 PM, Rich Persaud wrote: > >> On Dec 1, 2019, at 16:47, Mark Hatle <[email protected]> > 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 > [email protected] > http://lists.openembedded.org/mailman/listinfo/openembedded-architecture >
_______________________________________________ Openembedded-architecture mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
