Discussion: Version retention policy in oe-core

[Khem Raj]

On (22/02/11 15:33), Richard Purdie wrote:
> 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...


I tend to agree. If we have a new recipe then its better to make it
default and test it out well and we can fix fallouts in weekly kind of
testing or daily which will have larger coverage.
> 
> > 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
> 
> 
> 
> _______________________________________________
> tsc mailing list
> tsc at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/tsc

-- 
-Khem