I think this is a reasonable proposal, and one that should be able to be implemented fairly easily within the layer index code (and I'll help do it).
One problem with automated processes however is getting notification when they are malfunctioning. Case in point, the layer index is currently unable to parse OE-Core - or indeed any layer, since they all depend on OE-Core: https://bugzilla.yoctoproject.org/show_bug.cgi?id=13723 Unfortunately although it appears one change that relates to the error (the AVAILABLE_LICENSES change) went in earlier this month, I only found out about the issue on Friday, and only by accident when Mark stumbled over the error log - the reporting of parsing failures needs work. Consider also not just the failure of a part of the update script, as in this case, but a failure somewhere in the infrastructure to even start the script - that has happened before. I will continue to work on this in the New Year but right now the layer index isn't being updated for this reason. Paul On Saturday, 21 December 2019 2:37:24 PM NZDT 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.) > > > 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. > > > 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 > > 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 > -- Paul Eggleton Intel System Software Products _______________________________________________ Openembedded-architecture mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
