On 10/23/2014 08:56 AM, Flavio Percoco wrote:
> On 10/22/2014 08:15 PM, Doug Hellmann wrote:
>> The application projects are dropping python 2.6 support during Kilo, and 
>> I’ve had several people ask recently about what this means for Oslo. Because 
>> we create libraries that will be used by stable versions of projects that 
>> still need to run on 2.6, we are going to need to maintain support for 2.6 
>> in Oslo until Juno is no longer supported, at least for some of our 
>> projects. After Juno’s support period ends we can look again at dropping 2.6 
>> support in all of the projects.
>> I think these rules cover all of the cases we have:
>> 1. Any Oslo library in use by an API client that is used by a supported 
>> stable branch (Icehouse and Juno) needs to keep 2.6 support.
>> 2. If a client library needs a library we graduate from this point forward, 
>> we will need to ensure that library supports 2.6.
>> 3. Any Oslo library used directly by a supported stable branch of an 
>> application needs to keep 2.6 support.
>> 4. Any Oslo library graduated during Kilo can drop 2.6 support, unless one 
>> of the previous rules applies.
>> 5. The stable/icehouse and stable/juno branches of the incubator need to 
>> retain 2.6 support for as long as those versions are supported.
>> 6. The master branch of the incubator needs to retain 2.6 support until we 
>> graduate all of the modules that will go into libraries used by clients.
>> A few examples:
>> - oslo.utils was graduated during Juno and is used by some of the client 
>> libraries, so it needs to maintain python 2.6 support.
>> - oslo.config was graduated several releases ago and is used directly by the 
>> stable branches of the server projects, so it needs to maintain python 2.6 
>> support.
>> - oslo.log is being graduated in Kilo and is not yet in use by any projects, 
>> so it does not need python 2.6 support.
>> - oslo.cliutils and oslo.apiclient are on the list to graduate in Kilo, but 
>> both are used by client projects, so they need to keep python 2.6 support. 
>> At that point we can evaluate the code that remains in the incubator and see 
>> if we’re ready to turn of 2.6 support there.
>> Let me know if you have questions about any specific cases not listed in the 
>> examples.
> The rules look ok to me but I'm a bit worried that we might miss
> something in the process due to all these rules being in place. Would it
> be simpler to just say we'll keep py2.6 support in oslo for Kilo and
> drop it in Igloo (or L?) ?
> Once Igloo development begins, Kilo will be stable (without py2.6
> support except for Oslo) and Juno will be in security maintenance (with
> py2.6 support).

OMFG, did I really say Igloo? I should really consider taking a break.
Anyway, just read Igloo as the L release.

Seriously, WTF?

> I guess the TL;DR of what I'm proposing is to keep 2.6 support in oslo
> until we move the rest of the projects just to keep the process simpler.
> Probably longer but hopefully simpler.
> I'm sure I'm missing something so please, correct me here.
> Flavio

Flavio Percoco

OpenStack-dev mailing list

Reply via email to