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