Discussion: Version retention policy in oe-core

[Tom Rini]

On 02/22/2011 11:35 AM, 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.

This indeed is the problem I had on my mind with that 5 step dance.  I 
suppose if we had stuff being test built more widely before merge that 
problem might have been caught and then we could... say keep 2.28.x as 
D_P = -1 until everything is happy with it?

-- 
Tom Rini
Mentor Graphics Corporation