On Wednesday, 4 December 2019 4:23:18 AM NZDT akuster808 wrote: > On 12/2/19 6:28 AM, Mark Hatle wrote: > > On 12/1/19 10:52 PM, akuster808 wrote: > >> On 12/1/19 1:47 PM, Mark Hatle 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. > >>> > >>> > >>> So why the suggestion above? > >>> > >>> The URL one should be obvious, if the layer can no longer be downloaded > >>> then it > >>> should be removed. We should be able to detect when the index hasn't been > >>> updated in 90 days. (We could consider dropping this to 45 or even 30 > >>> days.) > >>> > >>> Looking for the last 3 releases give people the opportunity to update > >>> their > >>> layers, or other people to find layers that may be of interest to them and > >>> submit updates. After 18 months, the layer is clearly no longer being > >>> maintained and will cause more confusion then actually helping people find > >>> something useful. (Also after 18 months of inactivity, there is a much > >>> higher > >>> likelihood of security vulnerabilities in the code.) > >> Can we get a "Delete " button so I take that action myself for my Layers? > >> > >> Why put that burden on you and Paul? > > I thought if you were the owner of the layer you could already remove it > > yourself. > > Nope. All I can see I can do is change its status to "inactive". I don't > know what that does. Are there doc's ?
Right, there is no way for maintainers without admin rights to delete their own layers. Beyond the FAQ there aren't any docs, but if you're referring to the "Active/Inactive" field next to each maintainer that is just a flag that prevents that maintainer from showing up in the index entry (to anyone but admins and maintainers who can edit the layer). The idea was to make it easy to enable and disable maintainers who came and went and keep a record of who had been a maintainer in the past, but it's not really all that useful in practice. > > (You just have to login, otherwise contact Paul or I and we can do it > > pretty quickly.) > > This is what i want to avoid. I don't think this is so common an action that we need to allow maintainers to delete their own entries - we can take care of that. I'd rather there were some controls on layers getting deleted - if the original maintainer is dropping a layer, it might be decided in some cases that it's in everyone's best interest to have someone else pick it up immediately - depends on the layer and the situation. FWIW though I'm happy to grant yourself and others rights on the layer index as appropriate - in fact there are several others already have admin access (including Martin, Michael H, Nicolas, and Randy M) if we aren't around. One thing maintainers can do at any time is add a note on their layer to mark it as obsolete (with whatever text they want in the note). It might also be useful if there was a button there to send a message to the admins so people don't have to figure out who those are - that function could be implemented pretty easily. Cheers Paul -- Paul Eggleton Intel System Software Products _______________________________________________ Openembedded-architecture mailing list Openembedded-architecture@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
