Discussion: Version retention policy in oe-core

[Khem Raj]

On (28/02/11 18:56), Tom Rini wrote:
> On 02/28/2011 06:41 PM, Khem Raj wrote:
> >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 ?
> 
> To me, this is solved with our quarterly releases.  If something
> isn't _that_old_ but it's not the current one we want to keep
> anymore, there's a release that's probably less than 3 months old
> you can use that's known to work in the following combinations that
> has what you want in it.

thats like any standard desktop/server distros do. I dont think it
will fit all embedded use cases. I am thinking if its one recipe like
Koen mentioned will force someone not to upgrade to later releases
and we do have. So IMO a balance is better.

> 
> And while not for this thread but for another one, I think we want
> to encourage other layers to opt-in to being part of our quarterly
> releases to at least some degree of testing.  ie Angstrom might not
> say they've fully tested all of their combinations on 2011.09 but
> they've tested the following small set (and it at least builds, or
> passes the boot up to a login smoke test or ...).

>From distro POV I think it takes them longer to stabilize quarterly
could be a big ask for established distros like angstrom.
> 
> -- 
> Tom Rini
> Mentor Graphics Corporation
> 
> _______________________________________________
> tsc mailing list
> tsc at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/tsc

-- 
-Khem