[python-committers] [PSF-Members] Code Simplicity » Open Source Community, Simplified

Jesus Cea jcea at jcea.es
Sat Feb 5 00:23:49 CET 2011


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/02/11 20:55, Terry Reedy wrote:
>> Remember the rule: "Patches in n+1 are a SUPERSET of patches in n".
> 
> This is simply not true of 2.7 versus 3.2. 3.x is a fork off of 2.x at
> about 2.6. There are many 2.7-only bugs whose patches should not be
> forward ported, either 'by hand' or by auto merge.

Would be nice to know how many patches, currently, are traveling back
and forth between 2.7 and 3.x. I guess not many, and it will be less
every day.

I remember some decision, time ago, about not messing with 2.7 workflow,
because it is a dead branch. Do not pays to mess with it, tools,
integration, whatever, if its air supply is restricted to minimum. I
don't remember the details, sorry.

Anyway I can't tell how many patches applied to 2.7 are not in 3.x too.
Checking the last commits in 2.7, it seems we have quite a big overlap,
so "up porting" would be sensible.

Let's see:

"""
changeset:   45834:7849bb687f46
branch:      release27-maint
tag:         tip
user:        antoine.pitrou
date:        Fri Feb 04 21:17:53 2011 +0100
summary:     [svn r88336] Merged revisions 88334 via svnmerge from

changeset:   45833:4e7d4386cb5c
branch:      release27-maint
user:        eric.araujo
date:        Thu Feb 03 01:12:18 2011 +0100
summary:     [svn r88328] Merged revisions
86236,86240,86332,86340,87271,87273,87447 via svnmerge from

changeset:   45832:7e802a9f182c
branch:      release27-maint
user:        eric.araujo
date:        Wed Feb 02 18:03:38 2011 +0100
summary:     [svn r88320] Fix typo: BadZipFile exists in 3.2+ only, not
older versions.

changeset:   45831:9dc5b5c3e429
branch:      release27-maint
user:        raymond.hettinger
date:        Wed Feb 02 09:37:11 2011 +0100
summary:     [svn r88318] Issue 11089:  Fix performance bug in
ConfigParser that impaired its
"""

The merges are coming from somewhere. I assume they are backportings.
They could be equally developed in 2.7 and then up-ported via mercurial
merges.

svn r88320: It is a single line fix I can't see what is changed,
actually. What is the change?. Judging ONLY from the comment, it seems
it would be need to be applied to 3.1 branch. So it could be applied to
2.7, up-ported to 3.1 and possibly "null merged" in 3.2 (or mercurial
could consider it is not needed at all, because the code already has
that line!). This "null merge" would be a NOP when merging from 3.2 to
py3k trunk.

I think this bug was introduced when backporting (to 2.7 and 3.1) from
3.2. It would be not there if the original patch were developed in 2.7
and up-ported via mercurial merge. Kudos to the backporting workflow :).

svn r88318: http://bugs.python.org/issue11089 - This is a fix to apply
to 2.7, 3.1, 3.2 and py3k trunk. So, developing in 2.7 and up-porting
would be appropiate. too.

So, the last few patches applied to 2.7.x were applied too to 3.1.x,
3.2.x. So, up-porting seems a sensible approach. I don't see your point.
Do you want to check a few more patches, just to be sure that IN
GENERAL, patches in "n+1" are, and SHOULD BE, a superset of patches in
"n"?. My small survey is not a proof, but confirms that.

> (Note that from a temporal
> viewpoint, 2.7 -> 3.1 -> 3.2 is backwards, then forwards.)

In my book, 3.x came from 2.6, but 3.1 and 2.7 were basically developed
in sync, so considering 2.7 -> 3.1 -> 3.2 could not be the actual thing,
but it is a realistic assumption, for the new (hypothetical) new workflow.

Look at issue 11089. It is applied in 2.7 and 3.1, but it can't be
applied to 3.2 because we are in RC state now. Now, somebody *MUST*
remember to apply this patch when the 3.2 branch in open again. That is
a waste of mental energy for nothing.

If we don't close branches, and the beta/rc/final/maintenance is done in
clones, the thing would be:

1. Somebody opens issue 11089.

2. Somebody test versions affected. 2.7, 3.1 and 3.2 RC are affected.

3. A patch is developed *FIRST* *FOR* 2.7. Tested. Reviewed. Committed
to 2.7.

4. The patch propagate to 3.1 via a merge. This would be automatic, or
almost, with mercurial.

5. The patch should be applied to 3.2, but it is in RC already, so it is
applied to 3.2.1 clone, vía merge. Automatically done by mercurial. The
3.2.1 clone is done when the 3.2 clone moves to Release Candidate. 3.2.1
clone accumulates patches to be released in 3.2.1 and that can't be
applied to 3.2 because it is in RC state.

6. The patch is propagated to trunk (from 3.2.1) via another mercurial
merge.

This should be basically automatic, unless the patch need manual tweak
when merging. In this particular case, the code seems pretty trivial to
adjust, if necessary. This is not different that using svnmerge
backward, with the difference of keeping the history right and using the
mercurial machinery (three way merging and history tracking) to
automatically solve a lot of small details like file renaming, offsets
changings, whatever.

7. In the meantime, any patch to 3.2 clone (in RC state, so they should
be only a handful) is propagated to 3.2.1 clone and trunk clone, via
mercurial merge.

8. When 3.2(.0) is published, the 3.2 clone is open again. We
(atomatically) merge 3.2.1 clone to 3.2, and destroy 3.2.1. When time
come for 3.2.1 beta, we clone a 3.2.2 from 3.2 branch, and repeat.

In this schema, no developer has to WAIT for
anything/anybody/BETA/RC/Whatever.

I can see that having a 3.2.1 clone while 3.2 is closed complicates
things, but it has the huge advantage of not delaying any forward
progress. Anyway, this part is optional. You can forget the 3.2.1 clone
and simply forbid merging to 3.2 while is is in RC state. When 3.2 is
released, 3.1 is merged to 3.2, bringing all delayed patches. And people
waiting for 3.2 opening to commit new code, can do it now.

During 3.2 RC, you can merge to trunk from 3.1, for people working on
trunk to get the fixes. When you merge from 3.1 to 3.2, you get the
fixes there too. When merging 3.2 to trunk, later, Mercurial is clever
enough to skip over the changesets merged vía 3.1 and coming again thru
3.2. This is something you can't do with SVN.

> As a user of 3.x (and not 2.x), I will work on bug fixes for 3.x. If the
> bug involves 2.7 also and the fix transports easily to 2.7, fine. If
> not, someone who cares about 2.7 can do the additional work.

If what you are saying is that you don't want to waste your time porting
your 3.x fixes to 2.7, of even worse, developing your patches in 2.7 and
"up-porting to 3.x"... That is an entirely different topic.

With current python-dev commitment, any bug discovered in 3.1 that
affect 2.7, should be solved in both. In fact, 2.7 fixing should more
prioritary that 3.1, since 2.7.x is going to survive far longer that
3.1, 3.2, 3.3 and maybe 3.4...

- -- 
Jesus Cea Avion                         _/_/      _/_/_/        _/_/_/
jcea at jcea.es - http://www.jcea.es/     _/_/    _/_/  _/_/    _/_/  _/_/
jabber / xmpp:jcea at jabber.org         _/_/    _/_/          _/_/_/_/_/
.                              _/_/  _/_/    _/_/          _/_/  _/_/
"Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQCVAwUBTUyKhZlgi5GaxT1NAQL6NgP/SY6grnzbDL520mDmeeZv37UEkVleAU/z
6JTBoD8XLOJ3hqB1YkRbMTHIt5ySi8laOU5fl/4XltIuHwCfh5LFuFADJlnnno3q
/RFwlu8ol3wCb0IcjvnfeTJCoQmsq2BNmnwbaZi+eOKKljVfCibVQrrydHl8J74w
O6lbP7EtgJw=
=5guh
-----END PGP SIGNATURE-----


More information about the python-committers mailing list