[oe] 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 at 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 at 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 at windriver.com>
>>>> Reply-To: tsc at lists.openembedded.org
>>>> Organization: Wind River Systems
>>>> To:<tsc at 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 at 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