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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
