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

[Mark Hatle]

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