Discussion: Version retention policy in oe-core

[Tom Rini]

On 02/24/2011 02:05 PM, Mark Hatle wrote:
> 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).

Looks good to me, thanks for merging them together.  Anyone have any 
further thoughts before we call this a policy and wiki it?

-- 
Tom Rini
Mentor Graphics Corporation