-----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 _/_/ _/_/_/ _/_/_/ j...@jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ jabber / xmpp:j...@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----- _______________________________________________ python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers
