<br><br><div class="gmail_quote">On Tue, Nov 27, 2012 at 7:23 AM, Daniel P. Berrange <span dir="ltr"><<a href="mailto:berrange@redhat.com" target="_blank">berrange@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Mon, Nov 26, 2012 at 08:40:15AM -0800, Monty Taylor wrote:<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<br>
> 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<br>
> to 2.7 libs and then use backport packages like unittest2 to make<br>
> 2.6 happy.<br>
> - We can't REALLY start thinking about Python3 in earnest until a<br>
> RHEL release comes out with python 2.7, because 2.7/3.3 are needed<br>
> for source-code compatible code<br>
><br>
> Net result - pretty much exactly what we're doing today, it just<br>
> gets it down on paper a little better.<br>
><br>
> Thoughts? Disagreements?<br>
<br>
</div>Even ignoring the question of what versions distros we're targetting<br>
support, I think we should be conservative in both the base python<br>
version, and external dependancies in general. I observe that there is<br>
a general tendancy to move to the latest release of external depedencies<br>
very quickly. As an example, Fedora 17 (which is not exactly an old<br>
release - in fact it is the current up2date Fedora release still) is<br>
already unable to satisfy OpenStack's min version requirements for<br>
something as simple as pep8.<br>
<br>
The view seems to be that things like DevStack / virtualenvs make it<br>
easy to switch to newer versions, and so there's little-to-no downside.<br>
This is mostly prioritizing easier coding for developers, over ease of<br>
deployment & maintenence for both end users and distributors. Perhaps<br>
this was the right approach early in OpenStacks lifetime, but with<br>
people increasingly viewing OpenStack as production ready / maturing<br>
I think the current balance is wrong. Indeed I believe the overly eager<br>
switch to new versions is actively harmful to the community as a whole.<br>
<br>
I would like to see our guiding principal be to avoid min version upgrades<br>
unless there is a significant (ie show stopper) problem with existing min<br>
versions to is not practical to live with. If a new particular new feature<br>
is really desired, then structure things so that the new feature is only<br>
used if the corresponding version is available, and fallback to turning<br>
off that feature otherwise. This avoids the need to upgrade min version<br>
requirements, without preventing use of new features.<br>
<br>
To your specific point of Python base versions, my view is that we should<br>
aim for the lowest possible Python version. Yes, new python 2.7 version<br>
introduces shiny new features over 2.6, but in reality it is entirely<br>
practical to write OpenStack without requiring these new features. As for<br>
Python 3.0, it may remove many warts from Python 2.x, but I really don't<br></blockquote><div><br></div><div>It isn't about "shiny features," it's about support. Just as we don't have the resources to support old versions of OpenStack indefinitely, the Python development team has to declare EOL for older versions of Python.</div>
<div><br></div><div>Python 2.6 is currently only receiving security fixes. No other bug fixes or enhancements will be made. Even that level of support will stop in October of next year (<a href="http://www.python.org/download/releases/2.6.8/">http://www.python.org/download/releases/2.6.8/</a>).</div>
<div><br></div><div>Python 2.7 is receiving bug fixes now, but will be cut off from support after another few years. The cutoff date isn't set, yet, but that's not an excuse to stick with old tools.</div><div><br>
</div><div>Failure to move will mean we won't be able to use fixes for existing libraries that drop support for 2.x or take advantage of new libraries without any support for Python 2. The progress from 2.x to 3.x in the rest of the Python community is slow, but steady. Many developers are already targeting 3.3 first, with 2.7 (or earlier) support an afterthought. </div>
<div><br></div><div>Doug</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
see much compelling reason to even consider supporting to that. Python<br>
2.x is going to be around for a long time yet and I don't see any end<br>
user relevant features of OpenStack that would be blocked by us sticking<br>
with 2.x only and ignoring 3.x entirely. There is certainly plenty of<br>
downside to increasing the min python above 2.6 for both os vendors and<br>
end users.<br>
<br>
Regards,<br>
Daniel<br>
<span class="HOEnZb"><font color="#888888">--<br>
|: <a href="http://berrange.com" target="_blank">http://berrange.com</a> -o- <a href="http://www.flickr.com/photos/dberrange/" target="_blank">http://www.flickr.com/photos/dberrange/</a> :|<br>
|: <a href="http://libvirt.org" target="_blank">http://libvirt.org</a> -o- <a href="http://virt-manager.org" target="_blank">http://virt-manager.org</a> :|<br>
|: <a href="http://autobuild.org" target="_blank">http://autobuild.org</a> -o- <a href="http://search.cpan.org/~danberr/" target="_blank">http://search.cpan.org/~danberr/</a> :|<br>
|: <a href="http://entangle-photo.org" target="_blank">http://entangle-photo.org</a> -o- <a href="http://live.gnome.org/gtk-vnc" target="_blank">http://live.gnome.org/gtk-vnc</a> :|<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br>