Discussion: Version retention policy in oe-core

[Richard Purdie]

On Mon, 2011-02-21 at 17:53 -0700, Tom Rini wrote:
> As has been discussed in a few places, there needs to be a policy that 
> is followed about how long to retain old recipes within the oe-core 
> repository as well as what to do with older versions of things.  There 
> is a related question here of when to use DEFAULT_PREFERENCE = "-1".
> 
> We also have use cases such as:
> - Public distribution X uses version A (pins)
> - Private distribution X uses version A
> - 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.
> 
> After thinking about the brief discussion we had during todays TSC 
> meeting, I would like to propose the following:
> 
> The goal of oe-core is to keep the latest stable version.  Exceptions 
> will been needed for the toolchain components where architecture 
> requirements or upstream problems may dictate that we need multiple 
> versions (but versions for versions sake is not required, we are working 
> within an SCM and retrieval of older ".z" type releases is easy).  With 
> a release framework of X.Y.Z, going from X.Y.Z to X.Y.$((Z + 1)) should 
> be a simple git mv.  When a new stable release happens (using the above 
> example where 3.8 and 4.0 are both stable), 4.0 should be introduced 
> with a DEFAULT_PREFERENCE of -1 and not moved to be the default until 
> validation is complete for both oe-core and meta-oe using this version 
> and the defined (separate item...) validation targets.

I think this DEFAULT_PREFERENCE policy complicates testing a lot and I'm
not sure its intuitive or useful. Just to highlight this, you're
proposing someone increasing the version:

a) Commit the new version with DP = "-1"
b) Update some testing config to PREFER that version
c) Complete the testing
d) Commit a change removing the DP = "-1", remove the preference
e) Remove the old version

This assumes that people don't test their changes and I'd rather make
the assumption that for OE core, people do test them. I know Saul queues
up patch sets for testing on our autobuilder before sending pull
requests and I'm expecting others doing patch aggregation to do this
too. We still need to agree on testing for OE-core but I'd suggest what
Yocto is doing works well as a good smoke test.

I still think the versions problem is better dealt with by layer
handling tools. An an example, when a new revision of oecore appears, a
tool can be run against meta-oe over the new revisions. If those
revisions remove any .bb files, it can prompt to migrate those versions
to meta-oe or not. It could also presumably be run at a later date to
resurect a version if problems appear (although I'd assume oe-core would
revert in the case of serious problems).

There are a variety of ways to handle this but turning version changes
into a 5 point process isn't likely to do us any favours and there has
to be some better alternative...

> Related to this are:
> - We want to encourage distributions that are tracking the latest to try 
> and stay with the latest.

Agreed.

> - We want to encourage recipes which people are interested in to be 
> maintained long term to be maintained, long term, in meta-oe.

Also agreed.

> - 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).

We certainly need feedback on what works for people and what doesn't
yes.

Cheers,

Richard