On Mon, Mar 14, 2011 at 09:09:52AM -0700, Chris Larson wrote: > On Mon, Mar 14, 2011 at 8:58 AM, Tom Rini <[email protected]> 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 <[email protected]> > > Reply-To: [email protected] > > Organization: Wind River Systems > > To: <[email protected]> > > > > 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: [email protected]
pgp644vw7UUSc.pgp
Description: PGP signature
_______________________________________________ Openembedded-devel mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
