On 12/20/19 5:37 PM, Mark Hatle wrote: > I am proposing the following as a new policy for the layers in the layer > index. > Recently I have been working with the layer index and it's become clear that > 'master' is pretty much unusable as it stands. Below is my proposal to clean > this up and keep it clean. In addition to the proposal, at the end, I will > include the ramifications of implementing this proposal. (All day is current > as > of yesterday.) > > This proposal has been updated based on the feedback received from the > original > thread with the subject: layers.openembedded.org - suggestion to remove > obsolete > layers > > Layer Index Proposal > -------------------- > > Background: > > The layer index (layers.openembedded.org) provides a convenient method to > index > existing layers, as well as track the creation of new supported branches. > Currently the layer index indexes Yocto Project release branches (and > associated > OpenEmbedded and layers) starting with Danny 1.3 through Zeus 3.0, as well as > the master branch. > > The layer index is mostly used by people connecting their web browser and > reviewing things in a human readable form. However, we have automated > processes > that use this same information to help construct and manage projects. For > instance, ‘bitbake-layers layerindex-fetch <layer>’ can be used to query the > layer index, and download the layer and it’s layer dependencies into an > existing > project. > > Two problems have been identified: > > 1. As URLs change or git projects/servers go away, the layer index is not > updated to reflect a change or remove obsolete — inaccessible items. At a > minimum we need to identify layers no longer have valid URLs. > > 2. Layers that are obsolete and no longer maintained are still present and can > cause confusion and make it harder for users to identify useful components. > > There is value in carrying a layer in the index, even if it is not currently > valid, as this can induce users to fix and contribute changes to those layers. > However, after the layer has been invalid for a significant period of time it > can be detrimental to the project as it suggests to people that OpenEmbedded > and > Yocto Project layers are unmaintained, out of date and/or contain insecure > software. > > The following policy is being proposed for the layer index. The policy items > can be accomplished though automation, as described below. > > Policy: > > For all branches, the following criteria will be evaluated on a regular basis: > > - Is the layer URL still valid? > > If the layer URL has not been valid for 30 days or more, an email will be sent > to the registered layer maintainers and a note will be added to indicate this > layer appears to no longer be available, and will be removed unless the URL is > update. > > If the URL is updated, or becomes valid the note will be cleared once the URL > is > valid. > > After 90 days, the layer will be removed from the index as no longer > available. > > > - Does the layer claim to support (LAYERSERIES_COMPAT) that is compatible with > oe-core in that release branch? (Only applies to sumo and newer branches) > > If the layer does not claim to be compatible with the branch after 30 days, an > email will be sent to the registered layer maintainers and a note will be > added > to indicate the layer is not listed as compatible with oe-core on the specific > branch. > > If the LAYERSERIES_COMPAT is updated, the note will be removed. > > Further for the _master_ branch only, the following will be evaluated: > > - If the LAYERSERIES_COMPAT is not listed as compatible (see the previous > item), > has the layer’s “master related” branch been updated within the last 18 > months? > > If the layer is not compatible, and the branch has not been updated within the > last 18 months the layer will be removed from the “master branch” index as > inactive. Note: release branches are not expected to be affected by this > change! > > The above items will processed via automation. (See the attachment as to what > changes would occur if the above policy proposal is approved.)
Thanks for taking the time to put this together. > > > Additional Request > ------------------ > > During the initial proposal that was sent, another item was identified. Below > covers this suggested change to the layer index itself. > > It was request that we should add a delete or ‘unpublish’ button accessible to > the owners of the layer. It is my opinion that actually deleting the layer > should be reserved for layer index administrators to prevent bad actors from > removing layers that are otherwise still valid. Unpublishing a layer could > still cause temporary inconvenience, but would be very easy to revert. Well, I requested the removal of one of my layers over IRC or maybe it was an email. How do you know it was Me? > > > Attachment > ---------- > > The attachments are tables per branch. A few of the indications are > explained here: > > !URL - The URL is invalid > > !layer - the layer itself isn't valid, but the URL worked > > !Compat - The layer does not indicate it is compatible How is a layer identified that passes the yocto-check-layer or has been met the "Yocto Compatible" badge? Are we overloading "Compatible" here? > > Note - A note needs to be added to this layer in the index > > Email - The maintainer of the layer would be contacted prior (not yet slated > for > removal) > > Remove - the layer should be removed from this branch's index > > (master only) > > LAST - number of days since the last commit, if !COMPAT is detected. > > > Stats: > > (in all cases the number of layers with bad urls exceeds the 90 days.) > > Sumo - Remove 3 layers > - Add compat notes to 11 layers > > Thud - Remove 1 layer > - Add compat notes to 4 layers > > Warrior - Remove 5 layers > - Add compat notes to 2 layers > > Zeus - (no layers to remove) > - Add compat notes to 3 layers > > Master - Remove 129 layers > - Add compat notes to 103 layers > > _______________________________________________ > 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
