Discussion: Version retention policy in oe-core

[Tom Rini]

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.

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

-- 
Tom Rini
Mentor Graphics Corporation