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