Discussion: Version retention policy in oe-core

Discussion: Version retention policy in oe-core

[Tom Rini]

Hi all,

The TSC has discussed this item at the request of the community and has 
come up with the following recommendation which we are looking for 
feedback (positive/negative/neutral) before putting this up on the wiki.

-------- Original Message --------
Subject: Re: Discussion: Version retention policy in oe-core
Date: Thu, 24 Feb 2011 15:05:25 -0600
From: Mark Hatle <mark.hatle@windriver.com>
Reply-To: tsc@lists.openembedded.org
Organization: Wind River Systems
To: <tsc@lists.openembedded.org>

This is a follow on to Tom's original post.  The attempt is to merge his
original thoughts with my own.

---

As has been discussed in a few places, there needs to be a policy that
is followed about how long to retain (or when to replace) old recipes
within the oe-core repository as well as what to do with older versions 
of things.

It is expected that OE will have a related meta-oe or similar layers 
which older components can be moved into while they are still useful and 
desirable to maintain.  However, these will be alternative versions and 
not the "core" version any longer.

Within the oe-core we can divide the components into two classes. 
Critical infrastructure components and standard components.  The 
critical components include the toolchain, autotools, and key libraries. 
  Virtually everything else fits into the standard components bucket.

We also have use cases such as:
- Upstream provides provides support (new releases) and clear guidelines
on upgrading for version 4.0 (current), version 3.8 (previous and 
stable) and version 3.6 (further previous, stable).  Upstream is also 
working on version 4.1.x (unstable, active development).
- Upstream provides no clear policy about what's supported other than 
current.
- Community standards indicate a specific version should be used rather 
then the latest for some reason
- An architecture requires specific versions.

We would like to propose the following:

The goal of oe-core is to remain a stable, yet up-to-date set of 
software that forms the foundation of the Open Embedded world.  While 
not everyone will be able to agree on a broad definition of "stable, yet 
up-to-date" the following guidelines will help define the rules for the 
inclusion and/or replacement of different versions into the oe-core.

First, each of the packages need to be divided into two categories: 
Critical Infrastructure and Core components.  If an item is neither of 
these, then the oe-core is likely the wrong place for the component.

By default we want to use the latest stable version of each component. 
The latest stable version of each component is defined by the 
component's upstream. When there is no clear policy from upstream we 
simply have to apply best judgment.

There of course will be exceptions to the default policy.  However, when 
an exception occurs it must be clearly stated and documented when and 
why we did not use the latest stable version -- or why we may have 
multiple versions available of a given component.  This will allow us to 
reevaluate the exceptions on a timely basis and decide the exception is 
no longer reasonable.

Most of these exceptions will be located in the critical infrastructure
components, specifically the toolchains.  In many cases we will need to 
support variants of these components either for stability or 
architectural reasons.

Another common exception is to meet specific policy or compatibility 
objectives within the system, such as the need to support both GPLv2 and 
GPLv3 versions of selected components.

If multiple versions are provided, usually the latest stable version 
will be preferred, however best judgment will be used to determine the 
preferred version.

As existing versions of removed, if they are still desirable, they 
should be moved into meta-oe or a suitable layer.

We also have the issue of upcoming development versions it is suggested 
that upcoming development versions of software be worked on in specific 
development layers until they have reach sufficient maturity to be 
considered stable and ready for inclusion in oe-core.

Related to this are:
- We want to encourage distributions that are tracking the latest to try 
and stay with the latest.
- We want to encourage recipes which people are interested in to be 
maintained long term to be maintained, long term, in meta-oe.
- We want to encourage distributions to work with and add to / maintain 
the core rather than deciding we have too frequent of an unhelpful churn 
(which is to say 4.0.1 -> 4.0.2 of $whatever is good, 4.0.1 -> 4.4.3 of 
$whatever is not).

Re: Discussion: Version retention policy in oe-core

[Chris Larson]

On Mon, Mar 14, 2011 at 8:58 AM, Tom Rini <tom_rini@mentor.com> wrote:
> The TSC has discussed this item at the request of the community and has come
> up with the following recommendation which we are looking for feedback
> (positive/negative/neutral) before putting this up on the wiki.
>
> -------- Original Message --------
> Subject: Re: Discussion: Version retention policy in oe-core
> Date: Thu, 24 Feb 2011 15:05:25 -0600
> From: Mark Hatle <mark.hatle@windriver.com>
> Reply-To: tsc@lists.openembedded.org
> Organization: Wind River Systems
> To: <tsc@lists.openembedded.org>
>
> This is a follow on to Tom's original post.  The attempt is to merge his
> original thoughts with my own.
>
> ---
>
> As has been discussed in a few places, there needs to be a policy that
> is followed about how long to retain (or when to replace) old recipes
> within the oe-core repository as well as what to do with older versions of
> things.
>
> It is expected that OE will have a related meta-oe or similar layers which
> older components can be moved into while they are still useful and desirable
> to maintain.  However, these will be alternative versions and not the "core"
> version any longer.
>
> Within the oe-core we can divide the components into two classes. Critical
> infrastructure components and standard components.  The critical components
> include the toolchain, autotools, and key libraries.  Virtually everything
> else fits into the standard components bucket.
>
> We also have use cases such as:
> - Upstream provides provides support (new releases) and clear guidelines
> on upgrading for version 4.0 (current), version 3.8 (previous and stable)
> and version 3.6 (further previous, stable).  Upstream is also working on
> version 4.1.x (unstable, active development).
> - Upstream provides no clear policy about what's supported other than
> current.
> - Community standards indicate a specific version should be used rather then
> the latest for some reason
> - An architecture requires specific versions.
>
> We would like to propose the following:
>
> The goal of oe-core is to remain a stable, yet up-to-date set of software
> that forms the foundation of the Open Embedded world.  While not everyone
> will be able to agree on a broad definition of "stable, yet up-to-date" the
> following guidelines will help define the rules for the inclusion and/or
> replacement of different versions into the oe-core.
>
> First, each of the packages need to be divided into two categories: Critical
> Infrastructure and Core components.  If an item is neither of these, then
> the oe-core is likely the wrong place for the component.
>
> By default we want to use the latest stable version of each component. The
> latest stable version of each component is defined by the component's
> upstream. When there is no clear policy from upstream we simply have to
> apply best judgment.
>
> There of course will be exceptions to the default policy.  However, when an
> exception occurs it must be clearly stated and documented when and why we
> did not use the latest stable version -- or why we may have multiple
> versions available of a given component.  This will allow us to reevaluate
> the exceptions on a timely basis and decide the exception is no longer
> reasonable.
>
> Most of these exceptions will be located in the critical infrastructure
> components, specifically the toolchains.  In many cases we will need to
> support variants of these components either for stability or architectural
> reasons.
>
> Another common exception is to meet specific policy or compatibility
> objectives within the system, such as the need to support both GPLv2 and
> GPLv3 versions of selected components.
>
> If multiple versions are provided, usually the latest stable version will be
> preferred, however best judgment will be used to determine the preferred
> version.
>
> As existing versions of removed, if they are still desirable, they should be
> moved into meta-oe or a suitable layer.
>
> We also have the issue of upcoming development versions it is suggested that
> upcoming development versions of software be worked on in specific
> development layers until they have reach sufficient maturity to be
> considered stable and ready for inclusion in oe-core.
>
> Related to this are:
> - We want to encourage distributions that are tracking the latest to try and
> stay with the latest.
> - We want to encourage recipes which people are interested in to be
> maintained long term to be maintained, long term, in meta-oe.
> - We want to encourage distributions to work with and add to / maintain the
> core rather than deciding we have too frequent of an unhelpful churn (which
> is to say 4.0.1 -> 4.0.2 of $whatever is good, 4.0.1 -> 4.4.3 of $whatever
> is not).

This feedback probably won't be helpful, but this seems like a sane
plan all around to me.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics

Re: Discussion: Version retention policy in oe-core

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 5319 bytes --]

On Mon, Mar 14, 2011 at 09:09:52AM -0700, Chris Larson wrote:
> On Mon, Mar 14, 2011 at 8:58 AM, Tom Rini <tom_rini@mentor.com> wrote:
> > The TSC has discussed this item at the request of the community and has come
> > up with the following recommendation which we are looking for feedback
> > (positive/negative/neutral) before putting this up on the wiki.
> >
> > -------- Original Message --------
> > Subject: Re: Discussion: Version retention policy in oe-core
> > Date: Thu, 24 Feb 2011 15:05:25 -0600
> > From: Mark Hatle <mark.hatle@windriver.com>
> > Reply-To: tsc@lists.openembedded.org
> > Organization: Wind River Systems
> > To: <tsc@lists.openembedded.org>
> >
> > This is a follow on to Tom's original post.  The attempt is to merge his
> > original thoughts with my own.
> >
> > ---
> >
> > As has been discussed in a few places, there needs to be a policy that
> > is followed about how long to retain (or when to replace) old recipes
> > within the oe-core repository as well as what to do with older versions of
> > things.
> >
> > It is expected that OE will have a related meta-oe or similar layers which
> > older components can be moved into while they are still useful and desirable
> > to maintain.  However, these will be alternative versions and not the "core"
> > version any longer.
> >
> > Within the oe-core we can divide the components into two classes. Critical
> > infrastructure components and standard components.  The critical components
> > include the toolchain, autotools, and key libraries.  Virtually everything
> > else fits into the standard components bucket.
> >
> > We also have use cases such as:
> > - Upstream provides provides support (new releases) and clear guidelines
> > on upgrading for version 4.0 (current), version 3.8 (previous and stable)
> > and version 3.6 (further previous, stable).  Upstream is also working on
> > version 4.1.x (unstable, active development).
> > - Upstream provides no clear policy about what's supported other than
> > current.
> > - Community standards indicate a specific version should be used rather then
> > the latest for some reason
> > - An architecture requires specific versions.
> >
> > We would like to propose the following:
> >
> > The goal of oe-core is to remain a stable, yet up-to-date set of software
> > that forms the foundation of the Open Embedded world.  While not everyone
> > will be able to agree on a broad definition of "stable, yet up-to-date" the
> > following guidelines will help define the rules for the inclusion and/or
> > replacement of different versions into the oe-core.
> >
> > First, each of the packages need to be divided into two categories: Critical
> > Infrastructure and Core components.  If an item is neither of these, then
> > the oe-core is likely the wrong place for the component.
> >
> > By default we want to use the latest stable version of each component. The
> > latest stable version of each component is defined by the component's
> > upstream. When there is no clear policy from upstream we simply have to
> > apply best judgment.
> >
> > There of course will be exceptions to the default policy.  However, when an
> > exception occurs it must be clearly stated and documented when and why we
> > did not use the latest stable version -- or why we may have multiple
> > versions available of a given component.  This will allow us to reevaluate
> > the exceptions on a timely basis and decide the exception is no longer
> > reasonable.
> >
> > Most of these exceptions will be located in the critical infrastructure
> > components, specifically the toolchains.  In many cases we will need to
> > support variants of these components either for stability or architectural
> > reasons.
> >
> > Another common exception is to meet specific policy or compatibility
> > objectives within the system, such as the need to support both GPLv2 and
> > GPLv3 versions of selected components.
> >
> > If multiple versions are provided, usually the latest stable version will be
> > preferred, however best judgment will be used to determine the preferred
> > version.
> >
> > As existing versions of removed, if they are still desirable, they should be
> > moved into meta-oe or a suitable layer.
> >
> > We also have the issue of upcoming development versions it is suggested that
> > upcoming development versions of software be worked on in specific
> > development layers until they have reach sufficient maturity to be
> > considered stable and ready for inclusion in oe-core.
> >
> > Related to this are:
> > - We want to encourage distributions that are tracking the latest to try and
> > stay with the latest.
> > - We want to encourage recipes which people are interested in to be
> > maintained long term to be maintained, long term, in meta-oe.
> > - We want to encourage distributions to work with and add to / maintain the
> > core rather than deciding we have too frequent of an unhelpful churn (which
> > is to say 4.0.1 -> 4.0.2 of $whatever is good, 4.0.1 -> 4.4.3 of $whatever
> > is not).
> 
> This feedback probably won't be helpful, but this seems like a sane
> plan all around to me.

I agree

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Type: application/pgp-signature, Size: 205 bytes --]

Re: Discussion: Version retention policy in oe-core

[Frans Meulenbroeks]

2011/3/14 Martin Jansa <martin.jansa@gmail.com>:
> On Mon, Mar 14, 2011 at 09:09:52AM -0700, Chris Larson wrote:
>> On Mon, Mar 14, 2011 at 8:58 AM, Tom Rini <tom_rini@mentor.com> wrote:
>> > The TSC has discussed this item at the request of the community and has come
>> > up with the following recommendation which we are looking for feedback
>> > (positive/negative/neutral) before putting this up on the wiki.
>> >
>> > -------- Original Message --------
>> > Subject: Re: Discussion: Version retention policy in oe-core
>> > Date: Thu, 24 Feb 2011 15:05:25 -0600
>> > From: Mark Hatle <mark.hatle@windriver.com>
>> > Reply-To: tsc@lists.openembedded.org
>> > Organization: Wind River Systems
>> > To: <tsc@lists.openembedded.org>
>> >
>> > This is a follow on to Tom's original post.  The attempt is to merge his
>> > original thoughts with my own.
>> >
>> > ---
>> >
>> > As has been discussed in a few places, there needs to be a policy that
>> > is followed about how long to retain (or when to replace) old recipes
>> > within the oe-core repository as well as what to do with older versions of
>> > things.
>> >
>> > It is expected that OE will have a related meta-oe or similar layers which
>> > older components can be moved into while they are still useful and desirable
>> > to maintain.  However, these will be alternative versions and not the "core"
>> > version any longer.
>> >
>> > Within the oe-core we can divide the components into two classes. Critical
>> > infrastructure components and standard components.  The critical components
>> > include the toolchain, autotools, and key libraries.  Virtually everything
>> > else fits into the standard components bucket.
>> >
>> > We also have use cases such as:
>> > - Upstream provides provides support (new releases) and clear guidelines
>> > on upgrading for version 4.0 (current), version 3.8 (previous and stable)
>> > and version 3.6 (further previous, stable).  Upstream is also working on
>> > version 4.1.x (unstable, active development).
>> > - Upstream provides no clear policy about what's supported other than
>> > current.
>> > - Community standards indicate a specific version should be used rather then
>> > the latest for some reason
>> > - An architecture requires specific versions.
>> >
>> > We would like to propose the following:
>> >
>> > The goal of oe-core is to remain a stable, yet up-to-date set of software
>> > that forms the foundation of the Open Embedded world.  While not everyone
>> > will be able to agree on a broad definition of "stable, yet up-to-date" the
>> > following guidelines will help define the rules for the inclusion and/or
>> > replacement of different versions into the oe-core.
>> >
>> > First, each of the packages need to be divided into two categories: Critical
>> > Infrastructure and Core components.  If an item is neither of these, then
>> > the oe-core is likely the wrong place for the component.
>> >
>> > By default we want to use the latest stable version of each component. The
>> > latest stable version of each component is defined by the component's
>> > upstream. When there is no clear policy from upstream we simply have to
>> > apply best judgment.
>> >
>> > There of course will be exceptions to the default policy.  However, when an
>> > exception occurs it must be clearly stated and documented when and why we
>> > did not use the latest stable version -- or why we may have multiple
>> > versions available of a given component.  This will allow us to reevaluate
>> > the exceptions on a timely basis and decide the exception is no longer
>> > reasonable.
>> >
>> > Most of these exceptions will be located in the critical infrastructure
>> > components, specifically the toolchains.  In many cases we will need to
>> > support variants of these components either for stability or architectural
>> > reasons.
>> >
>> > Another common exception is to meet specific policy or compatibility
>> > objectives within the system, such as the need to support both GPLv2 and
>> > GPLv3 versions of selected components.
>> >
>> > If multiple versions are provided, usually the latest stable version will be
>> > preferred, however best judgment will be used to determine the preferred
>> > version.
>> >
>> > As existing versions of removed, if they are still desirable, they should be
>> > moved into meta-oe or a suitable layer.
>> >
>> > We also have the issue of upcoming development versions it is suggested that
>> > upcoming development versions of software be worked on in specific
>> > development layers until they have reach sufficient maturity to be
>> > considered stable and ready for inclusion in oe-core.
>> >
>> > Related to this are:
>> > - We want to encourage distributions that are tracking the latest to try and
>> > stay with the latest.
>> > - We want to encourage recipes which people are interested in to be
>> > maintained long term to be maintained, long term, in meta-oe.
>> > - We want to encourage distributions to work with and add to / maintain the
>> > core rather than deciding we have too frequent of an unhelpful churn (which
>> > is to say 4.0.1 -> 4.0.2 of $whatever is good, 4.0.1 -> 4.4.3 of $whatever
>> > is not).
>>
>> This feedback probably won't be helpful, but this seems like a sane
>> plan all around to me.
>
> I agree
>
> --
> Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com
>

Tom, TSC,

Overall this seems like a fine proposal to me. Thanks a lot for drafting it.

There are a few minor suggestions I would like to make.

First is to define which components are considered to be critical, as
for what is non-critical for one person might be critical for someone
else.
Leaving this open is bound to lead to discussion and disagreement
later on, perhaps better be clear about it upfront.

Second is the location of deprecated recipes.
As far as I know we haven't clearly defined what goes into meta-oe.
I have assumed that this is one layer that will (also) contain recipes
that are not part of oe-core.For example a recipe for a UPnP server or
a CD recording program.
Mixing deprecated oe-core and mainline non-core recipes in the same
tree will probably lead to confusion and perhaps even to people trying
to upgrade deprecated recipes in meta-oe.
In order to avoid that confusion is is probably better to give the
deprecated oe-core recipes their own layer (e.g. old-oe-core).

Apart from the above I feel it would be good if the TSC would discuss
the location of OE recipes that are non-core, and also draft a
retention policy for that location.
This might of course be similar or identical to the oe-core one.

Best regards, Frans

Re: Discussion: Version retention policy in oe-core

[Philip Balister]

On 03/14/2011 11:58 AM, Tom Rini wrote:
> Hi all,
>
> The TSC has discussed this item at the request of the community and has
> come up with the following recommendation which we are looking for
> feedback (positive/negative/neutral) before putting this up on the wiki.

Looks reasonable. One thing I did not see is asking people not to add a 
new recipe and delete the old one in separate commits. This makes it 
easier to figure out problems when they arise.

Philip

>
> -------- Original Message --------
> Subject: Re: Discussion: Version retention policy in oe-core
> Date: Thu, 24 Feb 2011 15:05:25 -0600
> From: Mark Hatle <mark.hatle@windriver.com>
> Reply-To: tsc@lists.openembedded.org
> Organization: Wind River Systems
> To: <tsc@lists.openembedded.org>
>
> This is a follow on to Tom's original post. The attempt is to merge his
> original thoughts with my own.
>
> ---
>
> As has been discussed in a few places, there needs to be a policy that
> is followed about how long to retain (or when to replace) old recipes
> within the oe-core repository as well as what to do with older versions
> of things.
>
> It is expected that OE will have a related meta-oe or similar layers
> which older components can be moved into while they are still useful and
> desirable to maintain. However, these will be alternative versions and
> not the "core" version any longer.
>
> Within the oe-core we can divide the components into two classes.
> Critical infrastructure components and standard components. The critical
> components include the toolchain, autotools, and key libraries.
> Virtually everything else fits into the standard components bucket.
>
> We also have use cases such as:
> - Upstream provides provides support (new releases) and clear guidelines
> on upgrading for version 4.0 (current), version 3.8 (previous and
> stable) and version 3.6 (further previous, stable). Upstream is also
> working on version 4.1.x (unstable, active development).
> - Upstream provides no clear policy about what's supported other than
> current.
> - Community standards indicate a specific version should be used rather
> then the latest for some reason
> - An architecture requires specific versions.
>
> We would like to propose the following:
>
> The goal of oe-core is to remain a stable, yet up-to-date set of
> software that forms the foundation of the Open Embedded world. While not
> everyone will be able to agree on a broad definition of "stable, yet
> up-to-date" the following guidelines will help define the rules for the
> inclusion and/or replacement of different versions into the oe-core.
>
> First, each of the packages need to be divided into two categories:
> Critical Infrastructure and Core components. If an item is neither of
> these, then the oe-core is likely the wrong place for the component.
>
> By default we want to use the latest stable version of each component.
> The latest stable version of each component is defined by the
> component's upstream. When there is no clear policy from upstream we
> simply have to apply best judgment.
>
> There of course will be exceptions to the default policy. However, when
> an exception occurs it must be clearly stated and documented when and
> why we did not use the latest stable version -- or why we may have
> multiple versions available of a given component. This will allow us to
> reevaluate the exceptions on a timely basis and decide the exception is
> no longer reasonable.
>
> Most of these exceptions will be located in the critical infrastructure
> components, specifically the toolchains. In many cases we will need to
> support variants of these components either for stability or
> architectural reasons.
>
> Another common exception is to meet specific policy or compatibility
> objectives within the system, such as the need to support both GPLv2 and
> GPLv3 versions of selected components.
>
> If multiple versions are provided, usually the latest stable version
> will be preferred, however best judgment will be used to determine the
> preferred version.
>
> As existing versions of removed, if they are still desirable, they
> should be moved into meta-oe or a suitable layer.
>
> We also have the issue of upcoming development versions it is suggested
> that upcoming development versions of software be worked on in specific
> development layers until they have reach sufficient maturity to be
> considered stable and ready for inclusion in oe-core.
>
> Related to this are:
> - We want to encourage distributions that are tracking the latest to try
> and stay with the latest.
> - We want to encourage recipes which people are interested in to be
> maintained long term to be maintained, long term, in meta-oe.
> - We want to encourage distributions to work with and add to / maintain
> the core rather than deciding we have too frequent of an unhelpful churn
> (which is to say 4.0.1 -> 4.0.2 of $whatever is good, 4.0.1 -> 4.4.3 of
> $whatever is not).
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: Discussion: Version retention policy in oe-core

[Chris Larson]

On Mon, Mar 14, 2011 at 3:22 PM, Philip Balister <philip@balister.org> wrote:
>> The TSC has discussed this item at the request of the community and has
>> come up with the following recommendation which we are looking for
>> feedback (positive/negative/neutral) before putting this up on the wiki.
>
> Looks reasonable. One thing I did not see is asking people not to add a new
> recipe and delete the old one in separate commits. This makes it easier to
> figure out problems when they arise.

I'd think this is a smaller piece of the general commit policies, and
in particular, bisectability, rather than version retention in
particular -- having a commit in the history where the recipe doesn't
exist would certainly violate bisectability, as it's hard to build
something that doesn't exist ;)
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics

Re: Discussion: Version retention policy in oe-core

[Tom Rini]

On 03/14/2011 03:22 PM, Philip Balister wrote:
> On 03/14/2011 11:58 AM, Tom Rini wrote:
>> Hi all,
>>
>> The TSC has discussed this item at the request of the community and has
>> come up with the following recommendation which we are looking for
>> feedback (positive/negative/neutral) before putting this up on the wiki.
>
> Looks reasonable. One thing I did not see is asking people not to add a
> new recipe and delete the old one in separate commits. This makes it
> easier to figure out problems when they arise.

So, part of what is envisioned here is that for, grabbing a recent 
example, nodejs 0.4.0 to 0.4.2 we just see a git mv, and that's the 
normal case for that level of things.  But for say 0.4.9 to 0.5.0 (or 
would it be 0.6.0?  I don't track the project, but next stable release 
that's not in 0.4.x) it would be add 0.5.0 one commit, drop 0.4.9 the 
next,  Does this still fit, given your comment?

>
> Philip
>
>>
>> -------- Original Message --------
>> Subject: Re: Discussion: Version retention policy in oe-core
>> Date: Thu, 24 Feb 2011 15:05:25 -0600
>> From: Mark Hatle <mark.hatle@windriver.com>
>> Reply-To: tsc@lists.openembedded.org
>> Organization: Wind River Systems
>> To: <tsc@lists.openembedded.org>
>>
>> This is a follow on to Tom's original post. The attempt is to merge his
>> original thoughts with my own.
>>
>> ---
>>
>> As has been discussed in a few places, there needs to be a policy that
>> is followed about how long to retain (or when to replace) old recipes
>> within the oe-core repository as well as what to do with older versions
>> of things.
>>
>> It is expected that OE will have a related meta-oe or similar layers
>> which older components can be moved into while they are still useful and
>> desirable to maintain. However, these will be alternative versions and
>> not the "core" version any longer.
>>
>> Within the oe-core we can divide the components into two classes.
>> Critical infrastructure components and standard components. The critical
>> components include the toolchain, autotools, and key libraries.
>> Virtually everything else fits into the standard components bucket.
>>
>> We also have use cases such as:
>> - Upstream provides provides support (new releases) and clear guidelines
>> on upgrading for version 4.0 (current), version 3.8 (previous and
>> stable) and version 3.6 (further previous, stable). Upstream is also
>> working on version 4.1.x (unstable, active development).
>> - Upstream provides no clear policy about what's supported other than
>> current.
>> - Community standards indicate a specific version should be used rather
>> then the latest for some reason
>> - An architecture requires specific versions.
>>
>> We would like to propose the following:
>>
>> The goal of oe-core is to remain a stable, yet up-to-date set of
>> software that forms the foundation of the Open Embedded world. While not
>> everyone will be able to agree on a broad definition of "stable, yet
>> up-to-date" the following guidelines will help define the rules for the
>> inclusion and/or replacement of different versions into the oe-core.
>>
>> First, each of the packages need to be divided into two categories:
>> Critical Infrastructure and Core components. If an item is neither of
>> these, then the oe-core is likely the wrong place for the component.
>>
>> By default we want to use the latest stable version of each component.
>> The latest stable version of each component is defined by the
>> component's upstream. When there is no clear policy from upstream we
>> simply have to apply best judgment.
>>
>> There of course will be exceptions to the default policy. However, when
>> an exception occurs it must be clearly stated and documented when and
>> why we did not use the latest stable version -- or why we may have
>> multiple versions available of a given component. This will allow us to
>> reevaluate the exceptions on a timely basis and decide the exception is
>> no longer reasonable.
>>
>> Most of these exceptions will be located in the critical infrastructure
>> components, specifically the toolchains. In many cases we will need to
>> support variants of these components either for stability or
>> architectural reasons.
>>
>> Another common exception is to meet specific policy or compatibility
>> objectives within the system, such as the need to support both GPLv2 and
>> GPLv3 versions of selected components.
>>
>> If multiple versions are provided, usually the latest stable version
>> will be preferred, however best judgment will be used to determine the
>> preferred version.
>>
>> As existing versions of removed, if they are still desirable, they
>> should be moved into meta-oe or a suitable layer.
>>
>> We also have the issue of upcoming development versions it is suggested
>> that upcoming development versions of software be worked on in specific
>> development layers until they have reach sufficient maturity to be
>> considered stable and ready for inclusion in oe-core.
>>
>> Related to this are:
>> - We want to encourage distributions that are tracking the latest to try
>> and stay with the latest.
>> - We want to encourage recipes which people are interested in to be
>> maintained long term to be maintained, long term, in meta-oe.
>> - We want to encourage distributions to work with and add to / maintain
>> the core rather than deciding we have too frequent of an unhelpful churn
>> (which is to say 4.0.1 -> 4.0.2 of $whatever is good, 4.0.1 -> 4.4.3 of
>> $whatever is not).
>>
>> _______________________________________________
>> Openembedded-devel mailing list
>> Openembedded-devel@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>


-- 
Tom Rini
Mentor Graphics Corporation

Re: Discussion: Version retention policy in oe-core

[Tom Rini]

On 03/14/2011 11:52 AM, Frans Meulenbroeks wrote:
> 2011/3/14 Martin Jansa<martin.jansa@gmail.com>:
>> On Mon, Mar 14, 2011 at 09:09:52AM -0700, Chris Larson wrote:
>>> On Mon, Mar 14, 2011 at 8:58 AM, Tom Rini<tom_rini@mentor.com>  wrote:
>>>> The TSC has discussed this item at the request of the community and has come
>>>> up with the following recommendation which we are looking for feedback
>>>> (positive/negative/neutral) before putting this up on the wiki.
>>>>
>>>> -------- Original Message --------
>>>> Subject: Re: Discussion: Version retention policy in oe-core
>>>> Date: Thu, 24 Feb 2011 15:05:25 -0600
>>>> From: Mark Hatle<mark.hatle@windriver.com>
>>>> Reply-To: tsc@lists.openembedded.org
>>>> Organization: Wind River Systems
>>>> To:<tsc@lists.openembedded.org>
>>>>
>>>> This is a follow on to Tom's original post.  The attempt is to merge his
>>>> original thoughts with my own.
>>>>
>>>> ---
>>>>
>>>> As has been discussed in a few places, there needs to be a policy that
>>>> is followed about how long to retain (or when to replace) old recipes
>>>> within the oe-core repository as well as what to do with older versions of
>>>> things.
>>>>
>>>> It is expected that OE will have a related meta-oe or similar layers which
>>>> older components can be moved into while they are still useful and desirable
>>>> to maintain.  However, these will be alternative versions and not the "core"
>>>> version any longer.
>>>>
>>>> Within the oe-core we can divide the components into two classes. Critical
>>>> infrastructure components and standard components.  The critical components
>>>> include the toolchain, autotools, and key libraries.  Virtually everything
>>>> else fits into the standard components bucket.
>>>>
>>>> We also have use cases such as:
>>>> - Upstream provides provides support (new releases) and clear guidelines
>>>> on upgrading for version 4.0 (current), version 3.8 (previous and stable)
>>>> and version 3.6 (further previous, stable).  Upstream is also working on
>>>> version 4.1.x (unstable, active development).
>>>> - Upstream provides no clear policy about what's supported other than
>>>> current.
>>>> - Community standards indicate a specific version should be used rather then
>>>> the latest for some reason
>>>> - An architecture requires specific versions.
>>>>
>>>> We would like to propose the following:
>>>>
>>>> The goal of oe-core is to remain a stable, yet up-to-date set of software
>>>> that forms the foundation of the Open Embedded world.  While not everyone
>>>> will be able to agree on a broad definition of "stable, yet up-to-date" the
>>>> following guidelines will help define the rules for the inclusion and/or
>>>> replacement of different versions into the oe-core.
>>>>
>>>> First, each of the packages need to be divided into two categories: Critical
>>>> Infrastructure and Core components.  If an item is neither of these, then
>>>> the oe-core is likely the wrong place for the component.
>>>>
>>>> By default we want to use the latest stable version of each component. The
>>>> latest stable version of each component is defined by the component's
>>>> upstream. When there is no clear policy from upstream we simply have to
>>>> apply best judgment.
>>>>
>>>> There of course will be exceptions to the default policy.  However, when an
>>>> exception occurs it must be clearly stated and documented when and why we
>>>> did not use the latest stable version -- or why we may have multiple
>>>> versions available of a given component.  This will allow us to reevaluate
>>>> the exceptions on a timely basis and decide the exception is no longer
>>>> reasonable.
>>>>
>>>> Most of these exceptions will be located in the critical infrastructure
>>>> components, specifically the toolchains.  In many cases we will need to
>>>> support variants of these components either for stability or architectural
>>>> reasons.
>>>>
>>>> Another common exception is to meet specific policy or compatibility
>>>> objectives within the system, such as the need to support both GPLv2 and
>>>> GPLv3 versions of selected components.
>>>>
>>>> If multiple versions are provided, usually the latest stable version will be
>>>> preferred, however best judgment will be used to determine the preferred
>>>> version.
>>>>
>>>> As existing versions of removed, if they are still desirable, they should be
>>>> moved into meta-oe or a suitable layer.
>>>>
>>>> We also have the issue of upcoming development versions it is suggested that
>>>> upcoming development versions of software be worked on in specific
>>>> development layers until they have reach sufficient maturity to be
>>>> considered stable and ready for inclusion in oe-core.
>>>>
>>>> Related to this are:
>>>> - We want to encourage distributions that are tracking the latest to try and
>>>> stay with the latest.
>>>> - We want to encourage recipes which people are interested in to be
>>>> maintained long term to be maintained, long term, in meta-oe.
>>>> - We want to encourage distributions to work with and add to / maintain the
>>>> core rather than deciding we have too frequent of an unhelpful churn (which
>>>> is to say 4.0.1 ->  4.0.2 of $whatever is good, 4.0.1 ->  4.4.3 of $whatever
>>>> is not).
>>>
>>> This feedback probably won't be helpful, but this seems like a sane
>>> plan all around to me.
>>
>> I agree
>>
>> --
>> Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com
>>
>
> Tom, TSC,
>
> Overall this seems like a fine proposal to me. Thanks a lot for drafting it.
>
> There are a few minor suggestions I would like to make.
>
> First is to define which components are considered to be critical, as
> for what is non-critical for one person might be critical for someone
> else.
> Leaving this open is bound to lead to discussion and disagreement
> later on, perhaps better be clear about it upfront.

We see that as outside of the scope of this policy but I agree it needs 
to be settled up, at least as a starting point sooner rather than later. 
  So that we don't forget, please ask us to put this on the agenda.

> Second is the location of deprecated recipes.
> As far as I know we haven't clearly defined what goes into meta-oe.

Well, that's up to OE at large, including how it's run.  We're just 
setting out how the core should work right now.

> I have assumed that this is one layer that will (also) contain recipes
> that are not part of oe-core.For example a recipe for a UPnP server or
> a CD recording program.

Correct.  We expect meta-oe to continue to hold things that are not 
essential but are useful and not distribution specific.

> Mixing deprecated oe-core and mainline non-core recipes in the same
> tree will probably lead to confusion and perhaps even to people trying
> to upgrade deprecated recipes in meta-oe.

Why?  If meta-oe doesn't need something that's deprecated in the core it 
shouldn't take it on.  If it does need something deprecated, we should 
try and figure out what can be done about that in order to fix that, or 
live with it (which is to say, if package A depends on package B no 
newer than version 2.0 and package B is now up to 3.2, is package A 
something that's really worth keeping?  Or should it perhaps go away?

> In order to avoid that confusion is is probably better to give the
> deprecated oe-core recipes their own layer (e.g. old-oe-core).

If something isn't needed, we don't want to have to carry it anywhere 
other than in the scm history.  If it's needed, it should be somewhere 
active so it can be used.  We can re-evaluate this at a later point in 
time if it's not working, but we discussed this and that was our 
conclusion (that's my recollection at least, the log can be checked over 
if needed).

> Apart from the above I feel it would be good if the TSC would discuss
> the location of OE recipes that are non-core, and also draft a
> retention policy for that location.
 > This might of course be similar or identical to the oe-core one.

So that we don't forget, please reply to the next TSC meeting agenda 
(which should be sent out sometime Wednesday, iirc) and it'll get put on 
the list.

-- 
Tom Rini
Mentor Graphics Corporation

Re: Discussion: Version retention policy in oe-core

[Frans Meulenbroeks]

Tom, thanks for the reply.

2011/3/15 Tom Rini <tom_rini@mentor.com>:
> On 03/14/2011 11:52 AM, Frans Meulenbroeks wrote:
>>

[cut out large part of text]

>> Overall this seems like a fine proposal to me. Thanks a lot for drafting
>> it.
>>
>> There are a few minor suggestions I would like to make.
>>
>> First is to define which components are considered to be critical, as
>> for what is non-critical for one person might be critical for someone
>> else.
>> Leaving this open is bound to lead to discussion and disagreement
>> later on, perhaps better be clear about it upfront.
>
> We see that as outside of the scope of this policy but I agree it needs to
> be settled up, at least as a starting point sooner rather than later.  So
> that we don't forget, please ask us to put this on the agenda.

I agree that that is outside the policy (but within the TSC domain).
I'll bring it up when I see the agenda.
Note that I am quite busy tomorrow so it might be (my) thursday
morning before I get to that.
>
>> Second is the location of deprecated recipes.
>> As far as I know we haven't clearly defined what goes into meta-oe.
>
> Well, that's up to OE at large, including how it's run.  We're just setting
> out how the core should work right now.

I understand, but as said before this is also a topic for the TSC
>
>> I have assumed that this is one layer that will (also) contain recipes
>> that are not part of oe-core.For example a recipe for a UPnP server or
>> a CD recording program.
>
> Correct.  We expect meta-oe to continue to hold things that are not
> essential but are useful and not distribution specific.
>
>> Mixing deprecated oe-core and mainline non-core recipes in the same
>> tree will probably lead to confusion and perhaps even to people trying
>> to upgrade deprecated recipes in meta-oe.
>
> Why?  If meta-oe doesn't need something that's deprecated in the core it
> shouldn't take it on.  If it does need something deprecated, we should try
> and figure out what can be done about that in order to fix that, or live
> with it (which is to say, if package A depends on package B no newer than
> version 2.0 and package B is now up to 3.2, is package A something that's
> really worth keeping?  Or should it perhaps go away?

Well there are two things I like to avoid.
First one is someone seeing a deprecated OE-core recipe in meta-oe.
Say this recipe is at 1.X. The person seeing this knows that upstream
is at 1.Y (Y > X), but is not aware that this recipe (and maybe 1.Y)
is in oe-core and starts to work at it.
Only later (e.g. when submitting changes) (s)he learns that actually
the newer version is in OE-core, and that all the work is wasted
timel. This is not an encouraging experience).
I think it would help if people are alerted that a newer version
exists in oe-core)

The second one is that we have many versions of the same recipe and no
one really cares or maintains these old versions. (if they are
maintained and used I have no objections against multiple versions,
but I am somewhat allergic to recipes that are kinda orphaned and
sometimes do not even build).

Btw that raises the following question: if a distro wants to pin (for
whatever reason) a certain recipe, but that version is not really
needed by other packages or so, does it still live in meta-oe? or
should it then eventually move into a distro specific overlay? I'm
especially thinking about distro's that are not too active in updating
their pinnings
>
>> In order to avoid that confusion is is probably better to give the
>> deprecated oe-core recipes their own layer (e.g. old-oe-core).
>
> If something isn't needed, we don't want to have to carry it anywhere other
> than in the scm history.  If it's needed, it should be somewhere active so
> it can be used.  We can re-evaluate this at a later point in time if it's
> not working, but we discussed this and that was our conclusion (that's my
> recollection at least, the log can be checked over if needed).

I'm not sure if I saw the last log.
Key in your remark is what defines "needed".
Also what I often see is that things are needed, but after a while
become unneeded and become somewhat orphaned.
>
>> Apart from the above I feel it would be good if the TSC would discuss
>> the location of OE recipes that are non-core, and also draft a
>> retention policy for that location.
>
>> This might of course be similar or identical to the oe-core one.
>
> So that we don't forget, please reply to the next TSC meeting agenda (which
> should be sent out sometime Wednesday, iirc) and it'll get put on the list.

will do.

Thanks for your reply.
Frans

Re: Discussion: Version retention policy in oe-core

[Philip Balister]

On 03/14/2011 07:13 PM, Tom Rini wrote:
> On 03/14/2011 03:22 PM, Philip Balister wrote:
>> On 03/14/2011 11:58 AM, Tom Rini wrote:
>>> Hi all,
>>>
>>> The TSC has discussed this item at the request of the community and has
>>> come up with the following recommendation which we are looking for
>>> feedback (positive/negative/neutral) before putting this up on the wiki.
>>
>> Looks reasonable. One thing I did not see is asking people not to add a
>> new recipe and delete the old one in separate commits. This makes it
>> easier to figure out problems when they arise.
>
> So, part of what is envisioned here is that for, grabbing a recent
> example, nodejs 0.4.0 to 0.4.2 we just see a git mv, and that's the
> normal case for that level of things. But for say 0.4.9 to 0.5.0 (or
> would it be 0.6.0? I don't track the project, but next stable release
> that's not in 0.4.x) it would be add 0.5.0 one commit, drop 0.4.9 the
> next, Does this still fit, given your comment?

The immediate case I am thinking off is the policykit-gnome update. 
(Which I think did the add/delete in the same commit). One of the 
changes was a configure option change that led to build failures on my 
F14 box. I'm not sure how this fits in the scheme you describe since the 
versioning seems to lack a major/minor concept. (Well the minor number 
is large)

In a perfect world, what you are describing is great, however I'm 
concerned the "special cases" may be an issue.

Philip


>
>>
>> Philip
>>
>>>
>>> -------- Original Message --------
>>> Subject: Re: Discussion: Version retention policy in oe-core
>>> Date: Thu, 24 Feb 2011 15:05:25 -0600
>>> From: Mark Hatle <mark.hatle@windriver.com>
>>> Reply-To: tsc@lists.openembedded.org
>>> Organization: Wind River Systems
>>> To: <tsc@lists.openembedded.org>
>>>
>>> This is a follow on to Tom's original post. The attempt is to merge his
>>> original thoughts with my own.
>>>
>>> ---
>>>
>>> As has been discussed in a few places, there needs to be a policy that
>>> is followed about how long to retain (or when to replace) old recipes
>>> within the oe-core repository as well as what to do with older versions
>>> of things.
>>>
>>> It is expected that OE will have a related meta-oe or similar layers
>>> which older components can be moved into while they are still useful and
>>> desirable to maintain. However, these will be alternative versions and
>>> not the "core" version any longer.
>>>
>>> Within the oe-core we can divide the components into two classes.
>>> Critical infrastructure components and standard components. The critical
>>> components include the toolchain, autotools, and key libraries.
>>> Virtually everything else fits into the standard components bucket.
>>>
>>> We also have use cases such as:
>>> - Upstream provides provides support (new releases) and clear guidelines
>>> on upgrading for version 4.0 (current), version 3.8 (previous and
>>> stable) and version 3.6 (further previous, stable). Upstream is also
>>> working on version 4.1.x (unstable, active development).
>>> - Upstream provides no clear policy about what's supported other than
>>> current.
>>> - Community standards indicate a specific version should be used rather
>>> then the latest for some reason
>>> - An architecture requires specific versions.
>>>
>>> We would like to propose the following:
>>>
>>> The goal of oe-core is to remain a stable, yet up-to-date set of
>>> software that forms the foundation of the Open Embedded world. While not
>>> everyone will be able to agree on a broad definition of "stable, yet
>>> up-to-date" the following guidelines will help define the rules for the
>>> inclusion and/or replacement of different versions into the oe-core.
>>>
>>> First, each of the packages need to be divided into two categories:
>>> Critical Infrastructure and Core components. If an item is neither of
>>> these, then the oe-core is likely the wrong place for the component.
>>>
>>> By default we want to use the latest stable version of each component.
>>> The latest stable version of each component is defined by the
>>> component's upstream. When there is no clear policy from upstream we
>>> simply have to apply best judgment.
>>>
>>> There of course will be exceptions to the default policy. However, when
>>> an exception occurs it must be clearly stated and documented when and
>>> why we did not use the latest stable version -- or why we may have
>>> multiple versions available of a given component. This will allow us to
>>> reevaluate the exceptions on a timely basis and decide the exception is
>>> no longer reasonable.
>>>
>>> Most of these exceptions will be located in the critical infrastructure
>>> components, specifically the toolchains. In many cases we will need to
>>> support variants of these components either for stability or
>>> architectural reasons.
>>>
>>> Another common exception is to meet specific policy or compatibility
>>> objectives within the system, such as the need to support both GPLv2 and
>>> GPLv3 versions of selected components.
>>>
>>> If multiple versions are provided, usually the latest stable version
>>> will be preferred, however best judgment will be used to determine the
>>> preferred version.
>>>
>>> As existing versions of removed, if they are still desirable, they
>>> should be moved into meta-oe or a suitable layer.
>>>
>>> We also have the issue of upcoming development versions it is suggested
>>> that upcoming development versions of software be worked on in specific
>>> development layers until they have reach sufficient maturity to be
>>> considered stable and ready for inclusion in oe-core.
>>>
>>> Related to this are:
>>> - We want to encourage distributions that are tracking the latest to try
>>> and stay with the latest.
>>> - We want to encourage recipes which people are interested in to be
>>> maintained long term to be maintained, long term, in meta-oe.
>>> - We want to encourage distributions to work with and add to / maintain
>>> the core rather than deciding we have too frequent of an unhelpful churn
>>> (which is to say 4.0.1 -> 4.0.2 of $whatever is good, 4.0.1 -> 4.4.3 of
>>> $whatever is not).
>>>
>>> _______________________________________________
>>> Openembedded-devel mailing list
>>> Openembedded-devel@lists.openembedded.org
>>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>>>
>>
>> _______________________________________________
>> Openembedded-devel mailing list
>> Openembedded-devel@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>>
>
>

Re: Discussion: Version retention policy in oe-core

[Tom Rini]

On 03/15/2011 06:14 AM, Philip Balister wrote:
> On 03/14/2011 07:13 PM, Tom Rini wrote:
>> On 03/14/2011 03:22 PM, Philip Balister wrote:
>>> On 03/14/2011 11:58 AM, Tom Rini wrote:
>>>> Hi all,
>>>>
>>>> The TSC has discussed this item at the request of the community and has
>>>> come up with the following recommendation which we are looking for
>>>> feedback (positive/negative/neutral) before putting this up on the
>>>> wiki.
>>>
>>> Looks reasonable. One thing I did not see is asking people not to add a
>>> new recipe and delete the old one in separate commits. This makes it
>>> easier to figure out problems when they arise.
>>
>> So, part of what is envisioned here is that for, grabbing a recent
>> example, nodejs 0.4.0 to 0.4.2 we just see a git mv, and that's the
>> normal case for that level of things. But for say 0.4.9 to 0.5.0 (or
>> would it be 0.6.0? I don't track the project, but next stable release
>> that's not in 0.4.x) it would be add 0.5.0 one commit, drop 0.4.9 the
>> next, Does this still fit, given your comment?
>
> The immediate case I am thinking off is the policykit-gnome update.
> (Which I think did the add/delete in the same commit). One of the
> changes was a configure option change that led to build failures on my
> F14 box. I'm not sure how this fits in the scheme you describe since the
> versioning seems to lack a major/minor concept. (Well the minor number
> is large)

So, policykit-gnome was just adding a new stable version (as default). 
The previous one is still there (in part because of pinning of 
dependencies to older versions).

Plugging this example into the workflow:
- policykit/policykit-gnome have newer stable versions released.
- Add new version as default, test[1]
- Keep old versions for now due to some distributions pinning glib-2.0 
to an older version that policykit > 0.98 (or so) need.

And, that brings us to [1].  FC14 seems to show off a class of bugs that 
need squashing.  I'd love it if someone can point me at a VMware 
compatible image (with functional tools) already installed.  That said, 
I think I meant to post to the ML and forgot, or no one saw the 
EXTRA_OECONF bug in the recipe that Koen fixed which I think fixes your 
problem.

> In a perfect world, what you are describing is great, however I'm
> concerned the "special cases" may be an issue.

The special cases being the critical infrastructure?  Or the unclear 
version policy?

-- 
Tom Rini
Mentor Graphics Corporation

Re: Discussion: Version retention policy in oe-core

[Tom Rini]

On 03/15/2011 02:38 AM, Frans Meulenbroeks wrote:
> Tom, thanks for the reply.
>
> 2011/3/15 Tom Rini<tom_rini@mentor.com>:
>> On 03/14/2011 11:52 AM, Frans Meulenbroeks wrote:
>>>
>
> [cut out large part of text]
>
>>> Overall this seems like a fine proposal to me. Thanks a lot for drafting
>>> it.
>>>
>>> There are a few minor suggestions I would like to make.
>>>
>>> First is to define which components are considered to be critical, as
>>> for what is non-critical for one person might be critical for someone
>>> else.
>>> Leaving this open is bound to lead to discussion and disagreement
>>> later on, perhaps better be clear about it upfront.
>>
>> We see that as outside of the scope of this policy but I agree it needs to
>> be settled up, at least as a starting point sooner rather than later.  So
>> that we don't forget, please ask us to put this on the agenda.
>
> I agree that that is outside the policy (but within the TSC domain).
> I'll bring it up when I see the agenda.
> Note that I am quite busy tomorrow so it might be (my) thursday
> morning before I get to that.

Thanks.

>>> Second is the location of deprecated recipes.
>>> As far as I know we haven't clearly defined what goes into meta-oe.
>>
>> Well, that's up to OE at large, including how it's run.  We're just setting
>> out how the core should work right now.
>
> I understand, but as said before this is also a topic for the TSC

One more agenda topic :)

>>> I have assumed that this is one layer that will (also) contain recipes
>>> that are not part of oe-core.For example a recipe for a UPnP server or
>>> a CD recording program.
>>
>> Correct.  We expect meta-oe to continue to hold things that are not
>> essential but are useful and not distribution specific.
>>
>>> Mixing deprecated oe-core and mainline non-core recipes in the same
>>> tree will probably lead to confusion and perhaps even to people trying
>>> to upgrade deprecated recipes in meta-oe.
>>
>> Why?  If meta-oe doesn't need something that's deprecated in the core it
>> shouldn't take it on.  If it does need something deprecated, we should try
>> and figure out what can be done about that in order to fix that, or live
>> with it (which is to say, if package A depends on package B no newer than
>> version 2.0 and package B is now up to 3.2, is package A something that's
>> really worth keeping?  Or should it perhaps go away?
>
> Well there are two things I like to avoid.
> First one is someone seeing a deprecated OE-core recipe in meta-oe.
> Say this recipe is at 1.X. The person seeing this knows that upstream
> is at 1.Y (Y>  X), but is not aware that this recipe (and maybe 1.Y)
> is in oe-core and starts to work at it.
> Only later (e.g. when submitting changes) (s)he learns that actually
> the newer version is in OE-core, and that all the work is wasted
> timel. This is not an encouraging experience).
> I think it would help if people are alerted that a newer version
> exists in oe-core)

I don't see this happening as you don't use meta-oe by itself but 
oe-core + meta-oe (+ possibly more).

> The second one is that we have many versions of the same recipe and no
> one really cares or maintains these old versions. (if they are
> maintained and used I have no objections against multiple versions,
> but I am somewhat allergic to recipes that are kinda orphaned and
> sometimes do not even build).

Right.  The default case isn't "throw it in meta-oe" when there's a new 
version but "is someone volunteering to take this into meta-oe because 
they need it".

> Btw that raises the following question: if a distro wants to pin (for
> whatever reason) a certain recipe, but that version is not really
> needed by other packages or so, does it still live in meta-oe? or
> should it then eventually move into a distro specific overlay? I'm
> especially thinking about distro's that are not too active in updating
> their pinnings

It's up to however meta-oe wants to run things.  It sounds like the 
desire is that if people are active and things work, it's fine to have 
things in meta-oe.

>>> In order to avoid that confusion is is probably better to give the
>>> deprecated oe-core recipes their own layer (e.g. old-oe-core).
>>
>> If something isn't needed, we don't want to have to carry it anywhere other
>> than in the scm history.  If it's needed, it should be somewhere active so
>> it can be used.  We can re-evaluate this at a later point in time if it's
>> not working, but we discussed this and that was our conclusion (that's my
>> recollection at least, the log can be checked over if needed).
>
> I'm not sure if I saw the last log.
> Key in your remark is what defines "needed".
> Also what I often see is that things are needed, but after a while
> become unneeded and become somewhat orphaned.

So, using a recent example.  policykit dropped needing eggdus build. 
And if we had (we didn't for various reasons) dropped the older versions 
and nothing else needed eggdbus, it too should have been brought up to 
the ML for removal.

But, no policy will be perfect in keeping the metadata from having no 
out of date / unused recipes and I'm sure we'll still run into "tried X, 
it didn't work and turns out to be real old and unmaintained."

>>> Apart from the above I feel it would be good if the TSC would discuss
>>> the location of OE recipes that are non-core, and also draft a
>>> retention policy for that location.
>>
>>> This might of course be similar or identical to the oe-core one.
>>
>> So that we don't forget, please reply to the next TSC meeting agenda (which
>> should be sent out sometime Wednesday, iirc) and it'll get put on the list.
>
> will do.

Thanks again. :)

-- 
Tom Rini
Mentor Graphics Corporation

Re: Discussion: Version retention policy in oe-core

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 15-03-11 16:53, Tom Rini wrote:
> On 03/15/2011 02:38 AM, Frans Meulenbroeks wrote:
>> Tom, thanks for the reply.
>>
>> 2011/3/15 Tom Rini<tom_rini@mentor.com>:
>>> On 03/14/2011 11:52 AM, Frans Meulenbroeks wrote:
>>>>
>>
>> [cut out large part of text]
>>
>>>> Overall this seems like a fine proposal to me. Thanks a lot for
>>>> drafting
>>>> it.
>>>>
>>>> There are a few minor suggestions I would like to make.
>>>>
>>>> First is to define which components are considered to be critical, as
>>>> for what is non-critical for one person might be critical for someone
>>>> else.
>>>> Leaving this open is bound to lead to discussion and disagreement
>>>> later on, perhaps better be clear about it upfront.
>>>
>>> We see that as outside of the scope of this policy but I agree it
>>> needs to
>>> be settled up, at least as a starting point sooner rather than
>>> later.  So
>>> that we don't forget, please ask us to put this on the agenda.
>>
>> I agree that that is outside the policy (but within the TSC domain).
>> I'll bring it up when I see the agenda.
>> Note that I am quite busy tomorrow so it might be (my) thursday
>> morning before I get to that.
> 
> Thanks.
> 
>>>> Second is the location of deprecated recipes.
>>>> As far as I know we haven't clearly defined what goes into meta-oe.
>>>
>>> Well, that's up to OE at large, including how it's run.  We're just
>>> setting
>>> out how the core should work right now.
>>
>> I understand, but as said before this is also a topic for the TSC
> 
> One more agenda topic :)
> 
>>>> I have assumed that this is one layer that will (also) contain recipes
>>>> that are not part of oe-core.For example a recipe for a UPnP server or
>>>> a CD recording program.
>>>
>>> Correct.  We expect meta-oe to continue to hold things that are not
>>> essential but are useful and not distribution specific.
>>>
>>>> Mixing deprecated oe-core and mainline non-core recipes in the same
>>>> tree will probably lead to confusion and perhaps even to people trying
>>>> to upgrade deprecated recipes in meta-oe.
>>>
>>> Why?  If meta-oe doesn't need something that's deprecated in the core it
>>> shouldn't take it on.  If it does need something deprecated, we
>>> should try
>>> and figure out what can be done about that in order to fix that, or live
>>> with it (which is to say, if package A depends on package B no newer
>>> than
>>> version 2.0 and package B is now up to 3.2, is package A something
>>> that's
>>> really worth keeping?  Or should it perhaps go away?
>>
>> Well there are two things I like to avoid.
>> First one is someone seeing a deprecated OE-core recipe in meta-oe.
>> Say this recipe is at 1.X. The person seeing this knows that upstream
>> is at 1.Y (Y>  X), but is not aware that this recipe (and maybe 1.Y)
>> is in oe-core and starts to work at it.
>> Only later (e.g. when submitting changes) (s)he learns that actually
>> the newer version is in OE-core, and that all the work is wasted
>> timel. This is not an encouraging experience).
>> I think it would help if people are alerted that a newer version
>> exists in oe-core)
> 
> I don't see this happening as you don't use meta-oe by itself but
> oe-core + meta-oe (+ possibly more).
> 
>> The second one is that we have many versions of the same recipe and no
>> one really cares or maintains these old versions. (if they are
>> maintained and used I have no objections against multiple versions,
>> but I am somewhat allergic to recipes that are kinda orphaned and
>> sometimes do not even build).
> 
> Right.  The default case isn't "throw it in meta-oe" when there's a new
> version but "is someone volunteering to take this into meta-oe because
> they need it".
> 
>> Btw that raises the following question: if a distro wants to pin (for
>> whatever reason) a certain recipe, but that version is not really
>> needed by other packages or so, does it still live in meta-oe? or
>> should it then eventually move into a distro specific overlay? I'm
>> especially thinking about distro's that are not too active in updating
>> their pinnings
> 
> It's up to however meta-oe wants to run things.  It sounds like the
> desire is that if people are active and things work, it's fine to have
> things in meta-oe.
> 
>>>> In order to avoid that confusion is is probably better to give the
>>>> deprecated oe-core recipes their own layer (e.g. old-oe-core).
>>>
>>> If something isn't needed, we don't want to have to carry it anywhere
>>> other
>>> than in the scm history.  If it's needed, it should be somewhere
>>> active so
>>> it can be used.  We can re-evaluate this at a later point in time if
>>> it's
>>> not working, but we discussed this and that was our conclusion
>>> (that's my
>>> recollection at least, the log can be checked over if needed).
>>
>> I'm not sure if I saw the last log.
>> Key in your remark is what defines "needed".
>> Also what I often see is that things are needed, but after a while
>> become unneeded and become somewhat orphaned.
> 
> So, using a recent example.  policykit dropped needing eggdus build.

FWIW, in the GNOME world anything with 'egg' in its name is a tech
that's in an incubation stage and scheduled to get merged into e.g.
libgnome, gtk, glib-2.0, etc. So if we stick to even releases we
shouldn't be needing any eggs. In a perfect world, that is :)

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFNf5JhMkyGM64RGpERAtQQAJ0fiVfoQgrwGsiv/IoJ0teB1qA76wCcDTAM
hHo9KrP5MvGUrs9tx6/gZCo=
=LMEy
-----END PGP SIGNATURE-----

Re: Discussion: Version retention policy in oe-core

[Frans Meulenbroeks]

2011/3/15 Tom Rini <tom_rini@mentor.com>:

>
> And, that brings us to [1].  FC14 seems to show off a class of bugs that
> need squashing.  I'd love it if someone can point me at a VMware compatible
> image (with functional tools) already installed.  That said, I think I meant
> to post to the ML and forgot, or no one saw the EXTRA_OECONF bug in the
> recipe that Koen fixed which I think fixes your problem.

There is a FC14  VM download at http://vmplanet.net/node/124
and there is probably also one or more torrents

e.g. found this: http://www.quotrader.org/vm/fedora14/

Haven't tried any of these, but will probably in a few days.

Frans

Re: Discussion: Version retention policy in oe-core

[Tom Rini]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/14/2011 08:58 AM, Tom Rini wrote:
> Hi all,
> 
> The TSC has discussed this item at the request of the community and has
> come up with the following recommendation which we are looking for
> feedback (positive/negative/neutral) before putting this up on the wiki.

Based on feedback I have placed this into
http://wiki.openembedded.org/index.php/Version_Retention_Policy

If any feedback is not incorporated it was unintentional and please let
me know so I can update it.  My reading of the feedback however came
down to:
- - Definition of what packages are in what category needs to be define
(separate task)
- - "Need to see how it works in practice" (agreed!).

Thanks all!

- -- 
Tom Rini
Mentor Graphics Corporation
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJNkOL6AAoJEI4NMjfc3nJxkFkIAM39xQlKT6/0CfVxS+KS6dty
AEpnVVXH6xfguY2oqYSi9pq0slt0IY5OQMl9LB8qSUU0KVZuxeTsXIAJLk6s2VN8
8/Q4kO8tgq0Y2c7m8xzXUka2pYQO9PgGfkibSVMdnmLLTDYaTa77tblLGYFqkVwq
g75s0/iJFyVvILhyApwSBnWdy6oV85KBm02ADcEFANCtsiL8QHgp2PMbWCe2QvcE
yVQ3/8tR9XZ3Niz9zzE7MvCkbds8DAJRc5tb8M4UzJQyUp+QFcb6awiBoOyhfr4f
R2brcosDDgb3bIZWuC9Ks/Cq1rqjEpkHXDU3NjvoxjVZlBGCQ/xq1BnEj9pQARY=
=mo/a
-----END PGP SIGNATURE-----

Re: Discussion: Version retention policy in oe-core

[Denys Dmytriyenko]

On Mon, Mar 28, 2011 at 12:35:22PM -0700, Tom Rini wrote:
> On 03/14/2011 08:58 AM, Tom Rini wrote:
> > Hi all,
> > 
> > The TSC has discussed this item at the request of the community and has
> > come up with the following recommendation which we are looking for
> > feedback (positive/negative/neutral) before putting this up on the wiki.
> 
> Based on feedback I have placed this into
> http://wiki.openembedded.org/index.php/Version_Retention_Policy
> 
> Tom Rini
> Mentor Graphics Corporation

Tom,

A slight offtopic: you started signing your emails, but where is the 
corresponding public key DCDE7271 - I cannot find it on any of the 
keyservers, although there are plenty of your old keys...

-- 
Denys

Re: Discussion: Version retention policy in oe-core

[Tom Rini]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/28/2011 01:15 PM, Denys Dmytriyenko wrote:
> On Mon, Mar 28, 2011 at 12:35:22PM -0700, Tom Rini wrote:
>> On 03/14/2011 08:58 AM, Tom Rini wrote:
>>> Hi all,
>>>
>>> The TSC has discussed this item at the request of the community and has
>>> come up with the following recommendation which we are looking for
>>> feedback (positive/negative/neutral) before putting this up on the wiki.
>>
>> Based on feedback I have placed this into
>> http://wiki.openembedded.org/index.php/Version_Retention_Policy
>>
>> Tom Rini
>> Mentor Graphics Corporation
> 
> Tom,
> 
> A slight offtopic: you started signing your emails, but where is the 
> corresponding public key DCDE7271 - I cannot find it on any of the 
> keyservers, although there are plenty of your old keys...

Blah, I didn't realize gpg2 --send-keys didn't work anymore.  It should
be on keyserver2.pgp.com in however long it takes for it to populate (I
can't find it in search just now but I also just clicked the
verification link).

- -- 
Tom Rini
Mentor Graphics Corporation
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJNkO/CAAoJEI4NMjfc3nJxmxkIALqNj55DpR9kxH+YTxE+CVVY
fHC+tBkCF8mR+NYQ3Qh6duwxBJXJdzWwDZivLow9iu9ej9i5vH5if7n+zsNfbw2+
c7nzZJh3fDk/oT3IRbXiM3CA4rpn/E4uSPGPa4uo0aOtT2NKwRYqrAKqlbWpaHku
DU2e1fN3H9+CMMXDbn4wjOuhCT+HIhaggzaD44zCm/15dK6M6u9ql6thAVq03Efw
x/Ft3nm3jBFhJPF7AEVzmYmI8LICtqUTSfjq6d7uBdnZQoqvnWfJQ9zKsmkBdJ6l
N/NFXX9SEajVc2c/Ez1mn6K32Uy2N36dR8ocmfPs+FVkf7UV0xQvmyhkmkAlNPA=
=dcsn
-----END PGP SIGNATURE-----

OT: Tom’s GPG key (was: Discussion: Version retention policy in oe-core)

[Paul Menzel]

[-- Attachment #1: Type: text/plain, Size: 1529 bytes --]

Am Montag, den 28.03.2011, 13:29 -0700 schrieb Tom Rini:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 03/28/2011 01:15 PM, Denys Dmytriyenko wrote:
> > On Mon, Mar 28, 2011 at 12:35:22PM -0700, Tom Rini wrote:
> >> On 03/14/2011 08:58 AM, Tom Rini wrote:
> >>> Hi all,
> >>>
> >>> The TSC has discussed this item at the request of the community and has
> >>> come up with the following recommendation which we are looking for
> >>> feedback (positive/negative/neutral) before putting this up on the wiki.
> >>
> >> Based on feedback I have placed this into
> >> http://wiki.openembedded.org/index.php/Version_Retention_Policy
> >>
> >> Tom Rini
> >> Mentor Graphics Corporation
> > 
> > Tom,
> > 
> > A slight offtopic: you started signing your emails, but where is the 
> > corresponding public key DCDE7271 - I cannot find it on any of the 
> > keyservers, although there are plenty of your old keys...
> 
> Blah, I didn't realize gpg2 --send-keys didn't work anymore.  It should
> be on keyserver2.pgp.com in however long it takes for it to populate (I
> can't find it in search just now but I also just clicked the
> verification link).

With `keyserver x-hkp://pool.sks-keyservers.net` in `~/.gnupg/gpg.conf`
Tom’s key is found.

        $ gpg --search-key DCDE7271
        gpg: suche nach "DCDE7271" auf hkp-Server pool.sks-keyservers.net
        (1)	Thomas Rini (work) <tom_rini@mentor.com>
        	  2048 bit RSA key DCDE7271, erzeugt: 2011-03-27


Thanks,

Paul

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 205 bytes --]