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

Tue Mar 15 13:14:17 UTC 2011

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 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).
>>>
>>> _______________________________________________
>>> Openembedded-devel mailing list
>>> Openembedded-devel at lists.openembedded.org
>>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>>>
>>
>> _______________________________________________
>> Openembedded-devel mailing list
>> Openembedded-devel at lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>>
>
>