Open Stack

On 10/22/2012 12:44 PM, Monty Taylor wrote:
> I'd also like a quick check in with folks on underlying distro support
> policy and about python 2.6 policy:
> 
> ****
> 
> Distro support
> 
> We're in a new situation right now. It's the first time we have an
> Ubuntu LTS in existence that we express some amount of support for.
> Previously, we have always targeted "latest ubuntu". There are three
> options I can see:
> 
> a) Continue to run tests for our development branches on precise until
> precise+1 comes out. Additionally, run tests on "latest ubuntu". This
> means during this cycle we'd run tests on precise and quantal.
> 
> b) Ignore LTS and continue to target "latest ubuntu" for testing. This
> mean during this cycle we'd move all build slaves to quantal.
> 
> c) Ignore quantal and target precise, either with or without the ubuntu
> cloud archive added.

For trunk testing, I think testing against the latest and greatest of
everything should be the primary target.  This helps us as a project
catch incompatibilities as soon as possible with stuff coming down the
pipe.  Of the choices, I'm advocating b.

Testing on more platforms (a) is beneficial, but starts to seem like the
testing is also serving as a distribution integration test bed, which
seems like something that should be a function of the distributions.

> 
> Additional item to consider:
> 
> - Do we or do we not enable the ubuntu cloud archive for any precise
> builders that we have (provides backports of dependencies)

If those builders stick around, that seems like a good idea since you
might as well match what people would actually be using.

> 2.6/3.x support
> 
> What do we do about python 2.6? Currently we have to run oneiric slaves
> for 2.6 testing because precise doesn't have it. I think swift cares
> about 2.6, but I don't think anyone else does. Swift has also been
> asking for lucid testing. Cutting off 2.6 support will be important for
> beginning to think about 3.x support.
> 
> Straw man proposal:
>  - Drop 2.6 testing support across the board for this cycle for the
> master branch. Add some lucid slaves and use them for testing of swift.
> (nothing other than swift has a chance in hell of working on lucid) Keep
> the current oneiric-based 2.6 jobs for 2.6 testing of
> stable/{diablo,essex,folsom}
>  - Moving forward, make plans for grizzly+1 to get swift off of 2.6 (is
> there any chance of that being reasonable notmyname?) so that we can
> start looking towards across the board support for 3.x. In the mean
> time, add some quantal builders with 3.3 installed and run some
> non-voting 3.3 jobs on some of the projects. (it's possible to have 2.7
> and 3.3 code that is source-code compatible)

I think an initial question around 2.6 support is where does 2.6 support
matter?  What distributions still use it?  (i.e. what is the impact of
the project dropping support for it?)  Once we determine the potential
impact, we can weigh that against the potential benefits of doing it.

RHEL 6.X and its derivatives (CentOS, Scientific Linux, ...) use 2.6.
Anything else?

-- 
Russell Bryant