On Tuesday, 3 December 2019 3:46:00 AM NZDT Mark Hatle wrote: > 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.)
Indeed, and I'd like to encourage more of this in future. If unmaintained layers could be marked in some way, perhaps with a link to suggested next steps for those interested in picking up the reins, I think that process would be facilitated. > 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. (As an aside, in case anyone wonders, we have not used this switch in the public index - it was added to the code for use in private instances.) > 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.) I think this seems reasonable. Additionally we can easily add flags with comments to layers that are considered unmaintained, that would show up in the web interface but could also be shown by Toaster, bitbake-layers and other places. (We do already have layer notes that can be used for this in a free-form manner, but an explicit flag would allow for easier filtering, possibly excluding such layers by default in certain contexts.) FYI, relating to this thread at Mark's suggestion I am already working on adding some fields to record when a layer was last successfully fetched, and when we last attempted to fetch it, so we can produce report on and/or automatically flag layers where the repo is gone for a long time (if we can't fetch a layer for e.g. 30 days, assuming it wasn't prevented from happening by some local issue I think we can safely assume it's gone). Cheers, Paul -- Paul Eggleton Intel System Software Products _______________________________________________ Openembedded-architecture mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
