Discussion: Version retention policy in oe-core

[Khem Raj]

On (22/02/11 19:35), Koen Kooi wrote:
> 
> Op 22 feb 2011, om 16:33 heeft Richard Purdie het volgende geschreven:
> 
> > 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 can give you an example from .dev where this can go wrong: glib 2.28. 
> 
> So for oe-core 2.28 would get added and a test build would get done and pass muster, but problems arise with gvfs in meta-oe, it suddenly doesn't build anymore. Using gvfs 1.7.x makes it build again, but you loose iDevice support.
> I'm not sure what the right way is to catch these kind of problems, but for breakage prone things (glib, ffmpeg, etc) adding it with DP = -1 might be the best way. But I suspect for most things that dance isn't needed.
> 

I see it as an oe-core API for other layers and similar problem can
occur with other layers which have dependencies between them. So may be
another layer to deprecate APIs could solve this problem ?

> > 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...
> 
> Agreed.
> 
> regards,
> 
> Koen
> _______________________________________________
> tsc mailing list
> tsc at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/tsc

-- 
-Khem