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
