[oe] Discussion: Version retention policy in oe-core

[Martin Jansa]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.openembedded.org/pipermail/openembedded-devel/attachments/20110314/c3409f95/attachment-0002.sig>