I think RedHat is heavily involved in supporting OpenStack and it behooves us to treat them well because of that.  I know they aren't always the easiest distribution to work with but that's also their strength.  But they are a bar worth raising ourselves up to.<br>
<br>Of course, I am driven to say that if someone, such as say SuSE grew to be more involved I would of course suggest we extend them the same courtesy.<br><br>The way I see it we'll never be able to avoid RHEL if openstack intends to operate in enterprise.  It's going to happen whether we want it to or not so we may as well embrace it.  But, we should let RedHat take care of the bits that really are their own concern.  And I say the same of SuSE.<br>
<br>Beyond that, everything that isn't ubuntu / debian is edge cases at the moment.<br><br>Windows and HyperV products for instance.  Or any potential port to a BSD or Solaris.  Those are big questions.  Especially since the HyperV team has contributed so much to OpenStack and has done incredible work.  Also because groups such as CERN who have been high profile and heavy contributors/supporters are relying on that contribution.  But I feel like at this point any work done there without significant user interest or adoption should be done at the expense of interested parties.  And that means keeping an open mind, and an open ear but not jumping through hoops to keep them in the proverbial engineering loop.<br>
<br>Opinions expressed are my own.<br><br>And maybe that's part of the question.  We can discuss to what extent this is an engineering concern.  But this also seems to fall at least partially under the purview of the OpenStack foundation board. <br>
<br>-Matt<br><br><div class="gmail_quote">On Mon, Nov 26, 2012 at 8:40 AM, Monty Taylor <span dir="ltr"><<a href="mailto:mordred@inaugust.com" target="_blank">mordred@inaugust.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hey all!<br>
<br>
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?"<br>

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

<br>
To put it more bluntly, if someone files a bug or a code review comment that says:<br>
<br>
"Blah doesn't work in python X"<br>
<br>
When can we respond "not a bug/won't fix" with a clear conscience?<br>
<br>
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.<br>

<br>
With that background, I'd like to start things off by proposing the following:<br>
<br>
a) We continue to focus development efforts of master on the latest release of Ubuntu with python libraries coming from PyPI.<br>
b) We don't introduce things into master that would be unworkable on either latest Ubuntu LTS or latest RHEL.<br>
<br>
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.<br>

<br>
Except where it comes to base python versions.<br>
<br>
If we take the above to be correct, it has the following effect:<br>
<br>
- We need to care about python 2.6 compatibility until such a time as there is a RHEL that has 2.7 in it.<br>
- 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.<br>
- 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<br>
<br>
Net result - pretty much exactly what we're doing today, it just gets it down on paper a little better.<br>
<br>
Thoughts? Disagreements?<br>
<br>
Monty<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</blockquote></div><br>