Open Stack

On 11/27/2012 06:17 AM, Mark McLoughlin wrote:
> On Tue, 2012-11-27 at 12:52 +0000, Daniel P. Berrange wrote:
>> On Mon, Nov 26, 2012 at 11:28:07PM +0000, Mark McLoughlin wrote:
>>>
>>>> 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.
>>
>> I'm of the opposite opinion really. There may be nice things in Python
>> 3.x, but when it actually comes down to it, the choice of 2.x vs 3.x
>> has little-to-no bearing on what features OpenStack supports, what
>> its user experience is, and what its deployment model is. What does make
>> a negative experiance as a person deploying / using OpenStack, is finding
>> out that your platform is too old and being forced to upgrade, or more
>> likely switch to an alternative cloud technology which does support your
>> current platform. IMHO, supporting Python 3.x adds little, and if it means
>> dropping 2.6 support, it could be considered actively harmful overall.
>>
>> Meanwhile there are plenty of things we could be doing to improve the
>> quality / scalability / ease of deployment for OpenStack that are
>> relevant to both 2.x and 3.x and would have much more significant
>> benefit for end users / deployers / vendors. eg switch to use a real
>> OS threading system so we can actually utilization large SMP hosts
>> effectively
>
> Mostly agree with all that, but the way I see the Python 3 issue is that
> Python 2 is eventually going to go away and we're going to need multiple
> release cycles of determined effort to be prepared for that.
>
> If there was a group showing that they are prepared to put in that
> determined effort, I'd prefer to support them rather than block that
> progress.
>
> If and when that time comes, though, I'd expect another group to be
> prepared to put in a determined effort to maintain 2.6 support (somehow)
> alongside the 3.x support. Those two groups would have to just muddle
> through somehow, perhaps not sharing the same branch.
>
> My point is pretty simple - no-one should feel that there are rules or
> mandates that prevents them getting starting on 3.x support.

++

I think that's a good summary of why I bring up 3.x. It' not that I want 
a new feature it has or something - it's that we are moving towards the 
world where 2.x is going away already. For instance, although I believe 
it will still have 2.x for a while, 3.x is intended to be the default 
python in the next Ubuntu LTS. It would not surprise me if 2.x went away 
by the one after that.

So at some point there is work in our future, and I'd love to get to the 
point where we can work on it incrementally.