Open Stack

Le 18/02/2016 14:15, Amrith Kumar a écrit :
> Let's definitely discuss this again once you have all the changes that you feel should be merged for Mitaka ready.

I don't like working on long patch series. In my experience, after more 
than 4 patches, it's more expensive to maintain the patch serie than to 
write patches. So I prefer to work on few patches, wait until they are 
merged, and then write following patches.

I'm not going to write dozens of patches. I suggest to do as I done in 
the paste, make progress with baby steps :-)

For example, my first change only changes the py34 test environment in 
tox.ini, it cannot break anything on Python 2, and it's enough to fix 
"tox -e py34". It is not in conflict with any other pending change.
https://review.openstack.org/#/c/279098/

 From this point, we can add a voting gate to be able to validate 
following Python 3 changes.


 > What I would like to avoid is a dribble of changes where we don't 
know how much more we have coming down the pike.

You have to be prepared for dozens of small patches. It only depends on 
the size of your project (number of code line numbers) :-)

To have an idea, you can see the Cinder blueprint which has an 
exhaustive list of all changes made for Python 3:
https://blueprints.launchpad.net/cinder/+spec/cinder-python3

I counted 100 patches between June 2015 and February 2016.

FYI with all my pending patches for Cinder (only 4 changes remain), all 
unit tests will pass on Python 3!

It also gives you an idea of the time frame: it took me 9 months to port 
Cinder unit tests to Python 3. So more than a single OpenStack cycle (6 
months).

Since the port is long and painful, I would like to start as soon as 
possible :-)


 > And while your changes may be "low risk", it does mean that if they 
merge now, the large feature sets that we have committed for this 
release will have to go through the cycle of merge conflicts, rebasing, 
code review, gate ... and so on.

The principle of technical debt is that the price only is only 
increasing if you wait longer :-) Merging Python 3 today or tomorrow 
doesn't solve the problem of merge conflicts :-)

It's really up to you to decide to "open the gate" for the flow of 
Python 3 patches, it's also up to you to control how much Python 3 
changes will merged. I can only offer my help to port code. I don't feel 
able to decide when it's the best time to start porting Trove ;-)

By the way, Gerrit provides a great "Conflicts With" information! It 
also helps to decide if it's ok to merge a Python 3 change, or if it's 
better to focus on the other changes in conflict.

Victor