On 12/21/19 12:57 PM, akuster808 wrote: > > > 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?
That's why I'm thinking unpublish might be better.. then removal later... > >> >> 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? This only refers to: LAYERSERIES_COMPAT Terminology here only is for the purposes of the report fitting in my window. :) --Mark >> 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
