Discussion: Version retention policy in oe-core

[Tom Rini]

On 02/28/2011 07:38 PM, Khem Raj wrote:
> 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.

Right.  But first, we're talking about oe-core not meta-oe.  In meta-oe 
things can be kept for as long as someone is willing to maintain them.

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

Note that I'm saying it should be opt-in.  And I'm hoping to be able to 
continue to provide build testing of a large matrix of things to help 
out here.

>>
>> --
>> Tom Rini
>> Mentor Graphics Corporation
>>
>> _______________________________________________
>> tsc mailing list
>> tsc at lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/tsc
>


-- 
Tom Rini
Mentor Graphics Corporation