[Openembedded-architecture] layers.openembedded.org - Layer Policy Proposal (revised)

Sat Dec 21 18:57:01 UTC 2019

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
> Openembedded-architecture at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-architecture

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-architecture/attachments/20191221/35c2c2c8/attachment.html>