-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/02/11 00:36, Antoine Pitrou wrote: > >> 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. > > That's because Raymond chose to break the usual workflow of fixing in > 3.2 first. If he had waited for 3.2 to unfreeze first, there would be no > "waste of mental energy for nothing".
In this case the issue should be open for the length of 3.2 RC state. In three weeks time your triage will vanish from memory and when 3.2 is open, "somebody" has to go back to this bug, refresh details already forgotten, write a patch for py3k trunk, "svnmerge" to 3.2, 3.1 and 2.7. If I discover a bug, triage it and can write a patch NOW, when all the details are fresh in my mind, I should do. Waiting because a branch is "closed" is a waste. If I can commit NOW and I know that patch propagation will be automatic via mercurial merges when the branch is open again, I rather prefer to solve it now, commit, and move on. People now must backport via "svnmerge", manually. Up-porting is automatic, via mercurial merges. You can't "leave a patch behind" because you forgot. It is simply not possible (you can do explicitly if a patch must not be up-ported, but that is the exception, not the rule). > That said, I don't think it's useful to discuss hg workflows at length. > We certainly already did so in the past, and nothing came out (otherwise > we wouldn't have this discussion again). Someone could sit and produce a > written proposal evaluating the various possibilities, and we can > iterate from that. I do agree. I am getting the feeling that (some not small group of) python core devs are not familiar with mercurial at all. That is a bit scary, considering the two years migration patch (and counting) and that to discuss workflow you must know the abilities of the tools... Really scary :). Do not consider my comment an attack. We are all busy people and change is painful. I sympathize, actually. But two years has been long enough... As a developer I think that "up porting" is the way to go. And I think that the "non block" clone philosophy should be something to aim. Actually the main problem I see there is buildbot infraestructure: if you keep more clones open (2.7, 2.7.x, 3.1, 3.1.x, 3.2, 3.2.x, trunk), buildbots should support that. More complicated yet if we want the option to include arbitrary repositories around in the buildbot infraestructure for, let say, developing long term features. 2.7: maintenance branch. 2.7.x: clone of 2.7 to host patches for 2.7.x when 2.7 is closed (RC state) getting ready for releasing 2.7.(x-1). - -- 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/ iQCVAwUBTUyTHplgi5GaxT1NAQKNlwP/U7F2PrAJ9/+tKiWg3wemKlxiPDlb42dV mpn5vLNVzZfj6p/nLkNroJiPce9CBL5pfGukD1Gqr+DG3IMh++xEXHk8EtZOPvPP Q/UUjXpHXDSnXtjugXL1nq4329oXUSJZSTIrCHRD6At2ykBBV5xRWDJvplU6zFw5 aMVTFAG3xVI= =nmyY -----END PGP SIGNATURE----- _______________________________________________ python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers
