Re: [Openembedded-architecture] layers.openembedded.org - suggestion to remove obsolete layers

[Paul Eggleton]

On Thursday, 5 December 2019 2:09:50 AM NZDT Tom Rini wrote:
> My concerns here are:
> - There's a lot of non-public projects out there not on "last 3" and
>   having older information is still useful.
> - As was already stated (but on my mind right now as I hop over to see
>   if anyone made recipes for X/Y/Z) being able to answer the question
>   of "a long time ago someone made a recipe for X" is useful.

Indeed, I can certainly see this as being useful. One thing that has been
discussed a long time ago (I think it was Martin's suggestion) is to make
recipes that only appear in older branches easier to find by showing them
when you do a recipe search in master - perhaps at the end of the normal
search results.
 
> So I would ask for more visual indicators that something is old rather
> than removing old things.

Yep, as long as we define what the criteria is (for setting flags either
manually or automatically) I think we can do that.

Cheers
Paul

-- 

Paul Eggleton
Intel System Software Products


___
Openembedded-architecture mailing list
Openembedded-architecture@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-architecture

Re: [Openembedded-architecture] layers.openembedded.org - suggestion to remove obsolete layers

[Tom Rini]

On Wed, Dec 04, 2019 at 08:20:56AM -0600, Mark Hatle wrote:
> 
> 
> On 12/4/19 7:09 AM, Tom Rini wrote:
> > On Sun, Dec 01, 2019 at 03:47:43PM -0600, Mark Hatle wrote:
> > 
> >> I've been looking through the layer index (master primarly), and I think 
> >> we need
> >> to figure out a policy of when to remove a layer from master indexing.
> >>
> >> So I'd like to suggest the following policy:
> >>
> >> - For released branches, we do not remove layers from the index unless the 
> >> layer
> >> URL is no longer valid.  If it is not valid for more then 90 days, we 
> >> should
> >> remove it.
> >>
> >> - For master branch, we use a series of tests to determine if the layer is 
> >> still
> >> actively maintained and useful to users:
> >>
> >>1. Is the layer URL valid?  If it has not been valid for more then 90 
> >> days,
> >> it should be removed.
> >>
> >>2. Does the layer claim to support any of the last three releases: the
> >> current (or planned release) or prior two releases?
> >>   i.e. LAYERSERIES_COMPAT does not have thud, warrior or zeus in it.
> >>
> >>   This means the layer has not been updated within the last 18 months, 
> >> and
> >> should be removed.
> >>
> >>
> >> So why the suggestion above?
> >>
> >> The URL one should be obvious, if the layer can no longer be downloaded 
> >> then it
> >> should be removed.  We should be able to detect when the index hasn't been
> >> updated in 90 days.  (We could consider dropping this to 45 or even 30 
> >> days.)
> >>
> >> Looking for the last 3 releases give people the opportunity to update their
> >> layers, or other people to find layers that may be of interest to them and
> >> submit updates.  After 18 months, the layer is clearly no longer being
> >> maintained and will cause more confusion then actually helping people find
> >> something useful.  (Also after 18 months of inactivity, there is a much 
> >> higher
> >> likelihood of security vulnerabilities in the code.)
> >>
> >>
> >> So if the TSC agrees that this is a good proposal, I can work with Paul to
> >> implement it (most likely manually at first, and then eventually via 
> >> automation.)
> > 
> > My concerns here are:
> > - There's a lot of non-public projects out there not on "last 3" and
> >   having older information is still useful.
> 
> I'm not suggesting removing layers from release branch indexes (unless the URL
> is no longer valid.)  It would primarily be removing it from master index.  
> (It
> does leave a gap that if it suddenly starts being worked on again, how do we
> know.  This could be accomplished using the same criteria in reverse, it 
> claims
> compatibility and has been updated within 18 months (or so)..
> 
> > - As was already stated (but on my mind right now as I hop over to see
> >   if anyone made recipes for X/Y/Z) being able to answer the question
> >   of "a long time ago someone made a recipe for X" is useful.
> > 
> > So I would ask for more visual indicators that something is old rather
> > than removing old things.
> 
> The problem I have is that if I use bitbake-layers layerindex-fetch  it
> can and will fetch a pile of garbage (non-maintained, non-functional layers) 
> now
> that will screw up my project.  I don't want any chance of obsolete code 
> ending
> up in my development projects as I work on things.  It diminishes the value of
> the layer index beyond someone just connecting and reading the output.

Maybe there's an important difference to be made between what the layer
website shows and this layerindex-fetch feature that I'm honestly just
now learning about but don't see it fitting in to my (or my customers)
use cases, but I'm sure is for others.

Either some field in the index to note "this may be old, don't give it
to layerindex-fetch" or some change within bitbake-layers to check for a
compatible branch/entry in master and throw up huge red flags on not
finding it?

-- 
Tom


signature.asc
Description: PGP signature
___
Openembedded-architecture mailing list
Openembedded-architecture@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-architecture

Re: [Openembedded-architecture] layers.openembedded.org - suggestion to remove obsolete layers

[Mark Hatle]

On 12/4/19 7:09 AM, Tom Rini wrote:
> On Sun, Dec 01, 2019 at 03:47:43PM -0600, Mark Hatle wrote:
> 
>> I've been looking through the layer index (master primarly), and I think we 
>> need
>> to figure out a policy of when to remove a layer from master indexing.
>>
>> So I'd like to suggest the following policy:
>>
>> - For released branches, we do not remove layers from the index unless the 
>> layer
>> URL is no longer valid.  If it is not valid for more then 90 days, we should
>> remove it.
>>
>> - For master branch, we use a series of tests to determine if the layer is 
>> still
>> actively maintained and useful to users:
>>
>>1. Is the layer URL valid?  If it has not been valid for more then 90 
>> days,
>> it should be removed.
>>
>>2. Does the layer claim to support any of the last three releases: the
>> current (or planned release) or prior two releases?
>>   i.e. LAYERSERIES_COMPAT does not have thud, warrior or zeus in it.
>>
>>   This means the layer has not been updated within the last 18 months, 
>> and
>> should be removed.
>>
>>
>> So why the suggestion above?
>>
>> The URL one should be obvious, if the layer can no longer be downloaded then 
>> it
>> should be removed.  We should be able to detect when the index hasn't been
>> updated in 90 days.  (We could consider dropping this to 45 or even 30 days.)
>>
>> Looking for the last 3 releases give people the opportunity to update their
>> layers, or other people to find layers that may be of interest to them and
>> submit updates.  After 18 months, the layer is clearly no longer being
>> maintained and will cause more confusion then actually helping people find
>> something useful.  (Also after 18 months of inactivity, there is a much 
>> higher
>> likelihood of security vulnerabilities in the code.)
>>
>>
>> So if the TSC agrees that this is a good proposal, I can work with Paul to
>> implement it (most likely manually at first, and then eventually via 
>> automation.)
> 
> My concerns here are:
> - There's a lot of non-public projects out there not on "last 3" and
>   having older information is still useful.

I'm not suggesting removing layers from release branch indexes (unless the URL
is no longer valid.)  It would primarily be removing it from master index.  (It
does leave a gap that if it suddenly starts being worked on again, how do we
know.  This could be accomplished using the same criteria in reverse, it claims
compatibility and has been updated within 18 months (or so)..

> - As was already stated (but on my mind right now as I hop over to see
>   if anyone made recipes for X/Y/Z) being able to answer the question
>   of "a long time ago someone made a recipe for X" is useful.
> 
> So I would ask for more visual indicators that something is old rather
> than removing old things.

The problem I have is that if I use bitbake-layers layerindex-fetch  it
can and will fetch a pile of garbage (non-maintained, non-functional layers) now
that will screw up my project.  I don't want any chance of obsolete code ending
up in my development projects as I work on things.  It diminishes the value of
the layer index beyond someone just connecting and reading the output.

--Mark
___
Openembedded-architecture mailing list
Openembedded-architecture@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-architecture

Re: [Openembedded-architecture] layers.openembedded.org - suggestion to remove obsolete layers

[Tom Rini]

On Sun, Dec 01, 2019 at 03:47:43PM -0600, Mark Hatle wrote:

> I've been looking through the layer index (master primarly), and I think we 
> need
> to figure out a policy of when to remove a layer from master indexing.
> 
> So I'd like to suggest the following policy:
> 
> - For released branches, we do not remove layers from the index unless the 
> layer
> URL is no longer valid.  If it is not valid for more then 90 days, we should
> remove it.
> 
> - For master branch, we use a series of tests to determine if the layer is 
> still
> actively maintained and useful to users:
> 
>1. Is the layer URL valid?  If it has not been valid for more then 90 days,
> it should be removed.
> 
>2. Does the layer claim to support any of the last three releases: the
> current (or planned release) or prior two releases?
>   i.e. LAYERSERIES_COMPAT does not have thud, warrior or zeus in it.
> 
>   This means the layer has not been updated within the last 18 months, and
> should be removed.
> 
> 
> So why the suggestion above?
> 
> The URL one should be obvious, if the layer can no longer be downloaded then 
> it
> should be removed.  We should be able to detect when the index hasn't been
> updated in 90 days.  (We could consider dropping this to 45 or even 30 days.)
> 
> Looking for the last 3 releases give people the opportunity to update their
> layers, or other people to find layers that may be of interest to them and
> submit updates.  After 18 months, the layer is clearly no longer being
> maintained and will cause more confusion then actually helping people find
> something useful.  (Also after 18 months of inactivity, there is a much higher
> likelihood of security vulnerabilities in the code.)
> 
> 
> So if the TSC agrees that this is a good proposal, I can work with Paul to
> implement it (most likely manually at first, and then eventually via 
> automation.)

My concerns here are:
- There's a lot of non-public projects out there not on "last 3" and
  having older information is still useful.
- As was already stated (but on my mind right now as I hop over to see
  if anyone made recipes for X/Y/Z) being able to answer the question
  of "a long time ago someone made a recipe for X" is useful.

So I would ask for more visual indicators that something is old rather
than removing old things.

-- 
Tom


signature.asc
Description: PGP signature
___
Openembedded-architecture mailing list
Openembedded-architecture@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-architecture

Re: [Openembedded-architecture] layers.openembedded.org - suggestion to remove obsolete layers

[Paul Eggleton]

On Tuesday, 3 December 2019 3:46:00 AM NZDT Mark Hatle wrote:
> On 12/2/19 8:30 AM, Martin Jansa wrote:
> > Even if the original URL isn't available anymore there might be some 
> > existing
> > forks on github or elsewhere.
> 
> But how would someone find it, and if they did find a fork how would they know
> it's 'authentic', i.e. not maliciously tampered with?
>
> It's one thing if someone forks it and maintains it, I'd hope/expect in that
> case they would try to take ownership on the layerindex.  (This has certainly
> happened in the past.)

Indeed, and I'd like to encourage more of this in future. If unmaintained 
layers could be marked in some way, perhaps with a link to suggested next steps 
for those interested in picking up the reins, I think that process would be 
facilitated.

> Yes, I'm only saying it is removed from master, not all of the index.
> 
> In the current layer index version there is a switch.  One is simply to stop
> indexing a particular layer.  This is not what I am suggesting.

(As an aside, in case anyone wonders, we have not used this switch in the 
public index - it was added to the code for use in private instances.)
 
> Instead what we could do is stop indexing/publishing new layer branches when 
> the
> LAYERCOMPAT doesn't match oe-core.
>
> This would allow a layer that still exists but is no longer functional to be
> disabled from master.. but if master and/or a new release branch is created it
> can validate and then publish.  (Once published it wouldn't be 'unpublished'
> from a release branch.  Also it wouldn't be unpublished/removed from master
> unless the suggested policy happens, i.e. URL goes away or it hasn't been
> updated in in 3 releases.)

I think this seems reasonable. Additionally we can easily add flags with 
comments to layers that are considered unmaintained, that would show up in the 
web interface but could also be shown by Toaster, bitbake-layers and other 
places. (We do already have layer notes that can be used for this in a 
free-form manner, but an explicit flag would allow for easier filtering, 
possibly excluding such layers by default in certain contexts.)

FYI, relating to this thread at Mark's suggestion I am already working on 
adding some fields to record when a layer was last successfully fetched, and 
when we last attempted to fetch it, so we can produce report on and/or 
automatically flag layers where the repo is gone for a long time (if we can't 
fetch a layer for e.g. 30 days, assuming it wasn't prevented from happening by 
some local issue I think we can safely assume it's gone).

Cheers,
Paul

-- 

Paul Eggleton
Intel System Software Products


___
Openembedded-architecture mailing list
Openembedded-architecture@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-architecture

Re: [Openembedded-architecture] layers.openembedded.org - suggestion to remove obsolete layers

[Mark Hatle]

On 12/2/19 8:30 AM, Martin Jansa wrote:
> Even if the original URL isn't available anymore there might be some existing
> forks on github or elsewhere.

But how would someone find it, and if they did find a fork how would they know
it's 'authentic', i.e. not maliciously tampered with?

It's one thing if someone forks it and maintains it, I'd hope/expect in that
case they would try to take ownership on the layerindex.  (This has certainly
happened in the past.)

> When searching for strange recipes, even finding the name of the layer where 
> it
> was before is sometimes useful to find it somewhere else - so I would prefer 
> to
> still be able to find it in the index even with clear warning that the 
> original
> repo is gone or seems unmaintained by some rules.
> 
> I agree that including whole unmaintained layer to build from master or latest
> release is often problematic, but many projects are still using old releases
> (this might happen even more often when LTS is available) where it still might
> work fine even with last commit in pyro branch 2 years ago and importing just 
> a
> few recipes from even older less maintained layer is still generally easy and
> useful starting point to start maintaining them somewhere else.

As long as the URL is valid, I would not ever suggest removing a layer from a
released branch.  Updating (or not) doesn't matter as the layer itself claims to
be compatible with that release branch.

> If some layer is actively used in project based on e.g. pyro, then I 
> understand
> that maintainer might be updating only pyro and if nobody steps in to maintain
> (and more importantly use and test the layer in project using newer release),
> then it looks unmaintained, but still useful for some people (and IMHO should 
> be
> discoverable on the index).

Yes, I'm only saying it is removed from master, not all of the index.

In the current layer index version there is a switch.  One is simply to stop
indexing a particular layer.  This is not what I am suggesting.

Instead what we could do is stop indexing/publishing new layer branches when the
LAYERCOMPAT doesn't match oe-core.

This would allow a layer that still exists but is no longer functional to be
disabled from master.. but if master and/or a new release branch is created it
can validate and then publish.  (Once published it wouldn't be 'unpublished'
from a release branch.  Also it wouldn't be unpublished/removed from master
unless the suggested policy happens, i.e. URL goes away or it hasn't been
updated in in 3 releases.)

--Mark

> On Mon, Dec 2, 2019 at 12:44 AM Mark Hatle  > wrote:
> 
> 
> 
> On 12/1/19 5:20 PM, Rich Persaud wrote:
> >> On Dec 1, 2019, at 16:47, Mark Hatle  > wrote:
> >>
> >>
> >> I've been looking through the layer index (master primarly), and I 
> think
> we need
> >> to figure out a policy of when to remove a layer from master indexing.
> >>
> >> So I'd like to suggest the following policy:
> >>
> >> - For released branches, we do not remove layers from the index unless
> the layer
> >> URL is no longer valid.  If it is not valid for more then 90 days, we 
> should
> >> remove it.
> >>
> >> - For master branch, we use a series of tests to determine if the layer
> is still
> >> actively maintained and useful to users:
> >>
> >> 1. Is the layer URL valid?  If it has not been valid for more then 90 
> days,
> >> it should be removed.
> >>
> >> 2. Does the layer claim to support any of the last three releases: the
> >> current (or planned release) or prior two releases?
> >>    i.e. LAYERSERIES_COMPAT does not have thud, warrior or zeus in it.
> >>
> >>    This means the layer has not been updated within the last 18 
> months, and
> >> should be removed.
> >
> > How about 90 days after a release date which crosses the threshold, or 
> 90
> days after a 1 week grace period for migration of the site hosting the
> layer?  That would give the maintainer a consistent 90-day notice for the
> two conditions which could trigger moving the layer to an "unmaintained"
> state. 
> 
> If the URL is not valid, then nobody can use it.  The maintainer could be
> notified, and the URL updated if it's moved.  If it has just been 
> removed, then
> it is useless to index it.
> 
> > As Adrian said, unmaintained layers could be later adopted or forked by 
> a
> new maintainer.  We may also want to archive layers for the historical
> record, e.g. at the time they are added to the index and/or periodically.
> 
> Current layer index I don't think there is any way to do this.  As long 
> as the
> URL is valid, this is possible -- but it would require us to have a way 
> to list
> obsolete layers without impacting layerindex users.  (Users include those 
> who
> connect 

Re: [Openembedded-architecture] layers.openembedded.org - suggestion to remove obsolete layers

[Adrian Bunk]

On Sun, Dec 01, 2019 at 04:20:45PM -0600, Mark Hatle wrote:
> 
> 
> On 12/1/19 4:01 PM, Adrian Bunk wrote:
> > On Sun, Dec 01, 2019 at 03:47:43PM -0600, Mark Hatle wrote:
> >> ...
> >> After 18 months, the layer is clearly no longer being
> >> maintained and will cause more confusion then actually helping people find
> >> something useful.
> >> ...
> > 
> > If it is not too much extra work, it would be useful if you could keep
> > a non-default way to show master including obsolete layers.
> > 
> > There are fringe usecases like "has anyone ever packaged this before".
> 
> There are ways to add comments within the Index itself.  However, there is no
> way to do this for users of the index, such as:
> 
> bitbake-layers layerindex-fetch 
> 
> I was doing this earlier and pulled in a couple of layers that clear do not
> work, and haven't been updated in a long time..  So it's a real issue that I
> think we need to address.

My usecase was searching for recipes at http://layers.openembedded.org

"fringe usecases" and "If it is not too much extra work" apply,
I cannot judge whether adding "master (including obsolete)" to
the web UI would be trivial or difficult.

> --Mark

cu
Adrian
___
Openembedded-architecture mailing list
Openembedded-architecture@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-architecture

Re: [Openembedded-architecture] layers.openembedded.org - suggestion to remove obsolete layers

[Mark Hatle]

On 12/1/19 5:20 PM, Rich Persaud wrote:
>> On Dec 1, 2019, at 16:47, Mark Hatle  wrote:
>>
>>
>> I've been looking through the layer index (master primarly), and I think we 
>> need
>> to figure out a policy of when to remove a layer from master indexing.
>>
>> So I'd like to suggest the following policy:
>>
>> - For released branches, we do not remove layers from the index unless the 
>> layer
>> URL is no longer valid.  If it is not valid for more then 90 days, we should
>> remove it.
>>
>> - For master branch, we use a series of tests to determine if the layer is 
>> still
>> actively maintained and useful to users:
>>
>> 1. Is the layer URL valid?  If it has not been valid for more then 90 days,
>> it should be removed.
>>
>> 2. Does the layer claim to support any of the last three releases: the
>> current (or planned release) or prior two releases?
>>i.e. LAYERSERIES_COMPAT does not have thud, warrior or zeus in it.
>>
>>This means the layer has not been updated within the last 18 months, and
>> should be removed.
> 
> How about 90 days after a release date which crosses the threshold, or 90 
> days after a 1 week grace period for migration of the site hosting the layer? 
>  That would give the maintainer a consistent 90-day notice for the two 
> conditions which could trigger moving the layer to an "unmaintained" state.  

If the URL is not valid, then nobody can use it.  The maintainer could be
notified, and the URL updated if it's moved.  If it has just been removed, then
it is useless to index it.

> As Adrian said, unmaintained layers could be later adopted or forked by a new 
> maintainer.  We may also want to archive layers for the historical record, 
> e.g. at the time they are added to the index and/or periodically.

Current layer index I don't think there is any way to do this.  As long as the
URL is valid, this is possible -- but it would require us to have a way to list
obsolete layers without impacting layerindex users.  (Users include those who
connect via web browsers, and tooling, such as bitbake-layers.)

--Mark

> Rich
> 
___
Openembedded-architecture mailing list
Openembedded-architecture@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-architecture

Re: [Openembedded-architecture] layers.openembedded.org - suggestion to remove obsolete layers

[Mark Hatle]

On 12/1/19 4:01 PM, Adrian Bunk wrote:
> On Sun, Dec 01, 2019 at 03:47:43PM -0600, Mark Hatle wrote:
>> ...
>> After 18 months, the layer is clearly no longer being
>> maintained and will cause more confusion then actually helping people find
>> something useful.
>> ...
> 
> If it is not too much extra work, it would be useful if you could keep
> a non-default way to show master including obsolete layers.
> 
> There are fringe usecases like "has anyone ever packaged this before".

There are ways to add comments within the Index itself.  However, there is no
way to do this for users of the index, such as:

bitbake-layers layerindex-fetch 

I was doing this earlier and pulled in a couple of layers that clear do not
work, and haven't been updated in a long time..  So it's a real issue that I
think we need to address.

--Mark

>> --Mark
> 
> cu
> Adrian
> 
___
Openembedded-architecture mailing list
Openembedded-architecture@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-architecture