Open Stack

Hey,

On Mon, 2012-11-26 at 08:40 -0800, Monty Taylor wrote:
> Hey all!
> 
> I started a discussion during a TC meeting a little while ago that needs 
> more general input and feedback. The question at hand is "what versions 
> of python and what versions of what distros do we care about as a project?"

Thanks for doing this.

> First of all, this isn't a discussion about what CI will test or what 
> we'll use for gating.  It's more of a conversation about what language 
> and OS assumptions developers can make when they are writing code, so 
> that design and review choices can be made.
> 
> To put it more bluntly, if someone files a bug or a code review comment 
> that says:
> 
> "Blah doesn't work in python X"
> 
> When can we respond "not a bug/won't fix" with a clear conscience?
> 
> When we first started the project, we said out loud that development was 
> always focused on the current release of Ubuntu and that's it. We picked 
> that because doing _development_ targeting a bazillion distro options at 
> the same time gets hairy quickly, and I think the clarity served has us 
> well. But I'm pretty sure things have changed since then - latest Ubuntu 
> does not come with python 2.6, for instance, but we still seem to care 
> about it.

Yeah, I think it's pretty obvious that things have moved on a little
since then.

> With that background, I'd like to start things off by proposing the 
> following:
> 
> a) We continue to focus development efforts of master on the latest 
> release of Ubuntu with python libraries coming from PyPI.

I'd say "latest release of Fedora" too - e.g. devstack not working on
the latest Fedora release would be understood as a bug by everyone IMHO.

I wouldn't discount us saying "latest release of Debian or SuSE" too.
I'm not just clear whether that's already the reality (i.e. we work on
two recent distros, other recent distros "just work" and no-one says
anything") or whether it really is just Ubuntu or Fedora we are
consistently in good shape on.

> b) We don't introduce things into master that would be unworkable on 
> either latest Ubuntu LTS or latest RHEL.

Never say never. Honestly, if someone showed up with fairly well
advanced support for Python 3.x and that meant we absolutely had to drop
Python 2.6 support, I'd be the first to say we should do it.

If that happened, Red Hat (and others) would have to just suck it up and
maintain patches for 2.6 support. I'd think we (as a project) would
provide whatever assistance is reasonable, though.

But ... that's theoretical at this point. I don't see any evidence of
imminent, complete and solid 3.x support.

> Logistically, because of our development focus on pypi modules in 
> virtualenvs, this doesn't affect much for developers outside of base 
> python versions and a few things that can't go in a virtualenv like 
> libvirt or the kernel. Since RedHat and Canonical have both committed to 
> maintaining special backport repos for those things for users of RHEL 
> and Ubuntu LTS, I don't think in practice it's going to have much of a 
> noticeable impact.
> 
> Except where it comes to base python versions.
> 
> If we take the above to be correct, it has the following effect:
> 
> - We need to care about python 2.6 compatibility until such a time as 
> there is a RHEL that has 2.7 in it.

Yes, but even then I don't see why we'd actively work to drop 2.6
support if no-one was working on 3.x support. The emphasis should be on
doing new, positive stuff rather than dropping support for stuff.

> - 2.7 should be our current dev focus, so if possible we should code to 
> 2.7 libs and then use backport packages like unittest2 to make 2.6 happy.

Yep.

> - We can't REALLY start thinking about Python3 in earnest until a RHEL 
> release comes out with python 2.7, because 2.7/3.3 are needed for 
> source-code compatible code

Honestly, if there was a determined group of people ready to make 3.x
support happen, I think a tonne of progress could be made (e.g. in side
branches) while the project itself continues to support 2.6.

An obvious example is eventlet - if there's no sign of eventlet being
supported on Python 3, then the first job for a group of determined
Python 3 hackers is to move us off eventlet. That doesn't (necessarily)
immediately require us to drop 2.6 support.

> Net result - pretty much exactly what we're doing today, it just gets it 
> down on paper a little better.
> 
> Thoughts? Disagreements?

Agree pretty much :)

Cheers,
Mark.