From steve at holdenweb.com Wed Feb 2 14:25:01 2011 From: steve at holdenweb.com (Steve Holden) Date: Wed, 2 Feb 2011 08:25:01 -0500 Subject: [python-committers] =?iso-8859-1?q?Code_Simplicity_=BB_Open_Sourc?= =?iso-8859-1?q?e_Community=2C_Simplified?= Message-ID: I imagine many of you will have seen this, but it's worth over-posting to make sure everyone gets to see it who is interested. http://www.codesimplicity.com/post/open-source-community-simplified/ regards Steve From mfoord at python.org Wed Feb 2 14:31:38 2011 From: mfoord at python.org (Michael Foord) Date: Wed, 02 Feb 2011 13:31:38 +0000 Subject: [python-committers] =?iso-8859-1?q?=5BPSF-Members=5D_Code_Simplic?= =?iso-8859-1?q?ity_=BB_Open_Source_Community=2C_Simplified?= In-Reply-To: References: Message-ID: <4D495CBA.6040706@python.org> On 02/02/2011 13:25, Steve Holden wrote: > I imagine many of you will have seen this, but it's worth over-posting to make sure everyone gets to see it who is interested. > > http://www.codesimplicity.com/post/open-source-community-simplified/ Thanks Steve. One issue it raises is the difficulties caused by freezing the trunk for releases. Instead they advocate creating the release branch at the point of the release candidate instead of freezing trunk. There are issues I currently *can't* work on because trunk is frozen and would personally prefer to see us use the branch-on-release-candidate process. All the best, Michael Foord > regards > Steve > _______________________________________________ > PSF-Members mailing list > PSF-Members at python.org > http://mail.python.org/mailman/listinfo/psf-members -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html From solipsis at pitrou.net Wed Feb 2 16:32:34 2011 From: solipsis at pitrou.net (Antoine Pitrou) Date: Wed, 02 Feb 2011 16:32:34 +0100 Subject: [python-committers] =?iso-8859-1?q?=5BPSF-Members=5D_Code_Simplic?= =?iso-8859-1?q?ity_=BB_Open_Source_Community=2C_Simplified?= In-Reply-To: <4D495CBA.6040706@python.org> References: <4D495CBA.6040706@python.org> Message-ID: <1296660754.3718.5.camel@localhost.localdomain> Great article, thank you Steve! Le mercredi 02 f?vrier 2011 ? 13:31 +0000, Michael Foord a ?crit : > On 02/02/2011 13:25, Steve Holden wrote: > > I imagine many of you will have seen this, but it's worth over-posting to make sure everyone gets to see it who is interested. > > > > http://www.codesimplicity.com/post/open-source-community-simplified/ > > Thanks Steve. > > One issue it raises is the difficulties caused by freezing the trunk for > releases. Instead they advocate creating the release branch at the point > of the release candidate instead of freezing trunk. > > There are issues I currently *can't* work on because trunk is frozen and > would personally prefer to see us use the branch-on-release-candidate > process. +11. This is one thing that makes me dread another release candidate. First, we did a survey of all our past developers who had left the project, asking them why they had left. This was just a free-form survey, allowing people to answer any way they wanted. Should we make our own survey of past contributors? Regards Antoine. From barry at python.org Wed Feb 2 17:47:02 2011 From: barry at python.org (Barry Warsaw) Date: Wed, 2 Feb 2011 11:47:02 -0500 Subject: [python-committers] =?utf-8?q?=5BPSF-Members=5D_Code_Simplicity_?= =?utf-8?q?=C2=BB_Open_Source_Community=2C_Simplified?= In-Reply-To: <4D495CBA.6040706@python.org> References: <4D495CBA.6040706@python.org> Message-ID: <20110202114702.133c59de@python.org> On Feb 02, 2011, at 01:31 PM, Michael Foord wrote: >One issue it raises is the difficulties caused by freezing the trunk for >releases. Instead they advocate creating the release branch at the point of >the release candidate instead of freezing trunk. There are issues I >currently *can't* work on because trunk is frozen and would personally prefer >to see us use the branch-on-release-candidate process. This is one of the primary problems solved by a dvcs. You can *always* and *easily* work on new features, publish them for comment and review by others, make continual progress regardless of the release status of the official branches, and easily track movement in those official branches. Pycon 2011 will mark the second anniversary of Guido's pronouncement. If we do nothing else in Atlanta, can we *please* *please* *please* come away from there with the conversion operationally completed? -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From jcea at jcea.es Wed Feb 2 18:26:26 2011 From: jcea at jcea.es (Jesus Cea) Date: Wed, 02 Feb 2011 18:26:26 +0100 Subject: [python-committers] =?iso-8859-15?q?=5BPSF-Members=5D_Code_Simpli?= =?iso-8859-15?q?city_=BB_Open_Source_Community=2C_Simplified?= In-Reply-To: <20110202114702.133c59de@python.org> References: <4D495CBA.6040706@python.org> <20110202114702.133c59de@python.org> Message-ID: <4D4993C2.9080909@jcea.es> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/02/11 17:47, Barry Warsaw wrote: > This is one of the primary problems solved by a dvcs. You can *always* and > *easily* work on new features, publish them for comment and review by others, > make continual progress regardless of the release status of the official > branches, and easily track movement in those official branches. That being true, I am interested in the buildbots. Publishing a private repository is not helpful, if you can't use the buildbots. I guess the best workflow would be for the Release Manager to create a clone, keeping the development repository open while the RM checks the clone and "cherry pick" changesets from the development branch if needed. When the release is complete, the clone can be tagged and merged back to the main development. So, nobody has to wait... > Pycon 2011 will mark the second anniversary of Guido's pronouncement. If we > do nothing else in Atlanta, can we *please* *please* *please* come away from > there with the conversion operationally completed? +inf!. - -- 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/ iQCVAwUBTUmTwplgi5GaxT1NAQIRbQP9FoUx5bcuwqiBVQczC2QBD7ad6ikVwN5e uf7ghaXkMltzUSgC5Bf3q+3yB/JVkfQ+gIK3TCvlQE+Kh7FlsKRd0MeKK62JDXwD U5YhKpX7CPGc14pM4+rEqaFuh5i/pbXNE8idNPd/kfk02CLt/+KKEoBwXmomm2cg Q/wUBlPrQZo= =M8ad -----END PGP SIGNATURE----- From solipsis at pitrou.net Wed Feb 2 18:38:47 2011 From: solipsis at pitrou.net (Antoine Pitrou) Date: Wed, 02 Feb 2011 18:38:47 +0100 Subject: [python-committers] =?iso-8859-1?q?=5BPSF-Members=5D_Code_Simplic?= =?iso-8859-1?q?ity_=BB_Open_Source_Community=2C_Simplified?= In-Reply-To: <4D4993C2.9080909@jcea.es> References: <4D495CBA.6040706@python.org> <20110202114702.133c59de@python.org> <4D4993C2.9080909@jcea.es> Message-ID: <1296668327.3718.8.camel@localhost.localdomain> Le mercredi 02 f?vrier 2011 ? 18:26 +0100, Jesus Cea a ?crit : > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 02/02/11 17:47, Barry Warsaw wrote: > > This is one of the primary problems solved by a dvcs. You can *always* and > > *easily* work on new features, publish them for comment and review by others, > > make continual progress regardless of the release status of the official > > branches, and easily track movement in those official branches. > > That being true, I am interested in the buildbots. Publishing a private > repository is not helpful, if you can't use the buildbots. > > I guess the best workflow would be for the Release Manager to create a > clone, keeping the development repository open while the RM checks the > clone and "cherry pick" changesets from the development branch if needed. That sounds like a full-time job for the poor Release Manager. We really need to merge changesets *ourselves*. It is irresponsible to expect someone else to do the grunt job of merging stuff. Regards Antoine. From jcea at jcea.es Wed Feb 2 19:21:07 2011 From: jcea at jcea.es (Jesus Cea) Date: Wed, 02 Feb 2011 19:21:07 +0100 Subject: [python-committers] =?iso-8859-15?q?=5BPSF-Members=5D_Code_Simpli?= =?iso-8859-15?q?city_=BB_Open_Source_Community=2C_Simplified?= In-Reply-To: <1296668327.3718.8.camel@localhost.localdomain> References: <4D495CBA.6040706@python.org> <20110202114702.133c59de@python.org> <4D4993C2.9080909@jcea.es> <1296668327.3718.8.camel@localhost.localdomain> Message-ID: <4D49A093.4020909@jcea.es> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/02/11 18:38, Antoine Pitrou wrote: >> I guess the best workflow would be for the Release Manager to create a >> clone, keeping the development repository open while the RM checks the >> clone and "cherry pick" changesets from the development branch if needed. > > That sounds like a full-time job for the poor Release Manager. We really > need to merge changesets *ourselves*. It is irresponsible to expect > someone else to do the grunt job of merging stuff. The merge here is mostly automatic. In fact, if the RM doesn't change his/her clone at all, the merge is "null", even if devel repository has evolved a lot in the meantime. The cost of the merge will be, usually, proportional to the "private" changesets done in the clone. If the only patches applied there are "backports" from the main development line (that is, backport to candidate release from the mainline), those "doesn't count" to the complexity. Ideally, a release candidate clone would have very few patches, and most of them coming from the main development (or main branch line). - -- 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/ iQCVAwUBTUmgk5lgi5GaxT1NAQKOIQQAnNQv+kol8bTr8nP6lM/29MQn7tz37QZv uWo2jBajMgpFWujawLEzxdW2hELjwplR8LdZc90hBbzXW182ePDQJJOZWUxKJPTW cLfYhMHKL8/CVTvEsOLsUr38ylvSd0spgch/7pUTc6Or/Xa9F9QM++D3bcAx9ndZ SmtaylMbb+k= =mSBR -----END PGP SIGNATURE----- From solipsis at pitrou.net Wed Feb 2 19:28:39 2011 From: solipsis at pitrou.net (Antoine Pitrou) Date: Wed, 02 Feb 2011 19:28:39 +0100 Subject: [python-committers] =?iso-8859-1?q?=5BPSF-Members=5D_Code_Simplic?= =?iso-8859-1?q?ity_=BB_Open_Source_Community=2C_Simplified?= In-Reply-To: <4D49A093.4020909@jcea.es> References: <4D495CBA.6040706@python.org> <20110202114702.133c59de@python.org> <4D4993C2.9080909@jcea.es> <1296668327.3718.8.camel@localhost.localdomain> <4D49A093.4020909@jcea.es> Message-ID: <1296671319.3718.9.camel@localhost.localdomain> Le mercredi 02 f?vrier 2011 ? 19:21 +0100, Jesus Cea a ?crit : > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 02/02/11 18:38, Antoine Pitrou wrote: > >> I guess the best workflow would be for the Release Manager to create a > >> clone, keeping the development repository open while the RM checks the > >> clone and "cherry pick" changesets from the development branch if needed. > > > > That sounds like a full-time job for the poor Release Manager. We really > > need to merge changesets *ourselves*. It is irresponsible to expect > > someone else to do the grunt job of merging stuff. > > The merge here is mostly automatic. In fact, if the RM doesn't change > his/her clone at all, the merge is "null", even if devel repository has > evolved a lot in the meantime. By merge I meant the cherry picking operation itself ("svnmerge"). From jcea at jcea.es Wed Feb 2 19:39:12 2011 From: jcea at jcea.es (Jesus Cea) Date: Wed, 02 Feb 2011 19:39:12 +0100 Subject: [python-committers] =?iso-8859-15?q?=5BPSF-Members=5D_Code_Simpli?= =?iso-8859-15?q?city_=BB_Open_Source_Community=2C_Simplified?= In-Reply-To: <1296671319.3718.9.camel@localhost.localdomain> References: <4D495CBA.6040706@python.org> <20110202114702.133c59de@python.org> <4D4993C2.9080909@jcea.es> <1296668327.3718.8.camel@localhost.localdomain> <4D49A093.4020909@jcea.es> <1296671319.3718.9.camel@localhost.localdomain> Message-ID: <4D49A4D0.8070908@jcea.es> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/02/11 19:28, Antoine Pitrou wrote: >> The merge here is mostly automatic. In fact, if the RM doesn't change >> his/her clone at all, the merge is "null", even if devel repository has >> evolved a lot in the meantime. > > By merge I meant the cherry picking operation itself ("svnmerge"). To be concrete, how many patches went inside 2.7.0 after cutting the "rc1"?. Ideally, the answer should be "a handful". AFAIK, there are issues when you cherry pick patches and then you try to merge back (same patch present in both lines, but no metadata saying so). But that seems an issue with current HG/cherrypick extension, not with an abstract mercurial inability. In fact, python could be a push to improve that in HG. - -- 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/ iQCVAwUBTUmkz5lgi5GaxT1NAQI3HAP9GJ5bKP6LNkzve9j/VIJM8JDUNecEJ8w7 Sqz6WSG4SLan15kFF/IyMbZoCkGDdDqmm8Ut0WpV5tIjByt4SgIJeLk8FyBM4WgW rEbHocufkF8STL3B/skgODUd10jgnKK1DZtZfv/zYVWsKBlXq8P1pSUTN8EegWwp qlFYAP+slrA= =Ckcz -----END PGP SIGNATURE----- From solipsis at pitrou.net Wed Feb 2 19:47:09 2011 From: solipsis at pitrou.net (Antoine Pitrou) Date: Wed, 02 Feb 2011 19:47:09 +0100 Subject: [python-committers] =?iso-8859-1?q?=5BPSF-Members=5D_Code_Simplic?= =?iso-8859-1?q?ity_=BB_Open_Source_Community=2C_Simplified?= In-Reply-To: <4D49A4D0.8070908@jcea.es> References: <4D495CBA.6040706@python.org> <20110202114702.133c59de@python.org> <4D4993C2.9080909@jcea.es> <1296668327.3718.8.camel@localhost.localdomain> <4D49A093.4020909@jcea.es> <1296671319.3718.9.camel@localhost.localdomain> <4D49A4D0.8070908@jcea.es> Message-ID: <1296672429.3718.12.camel@localhost.localdomain> Le mercredi 02 f?vrier 2011 ? 19:39 +0100, Jesus Cea a ?crit : > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 02/02/11 19:28, Antoine Pitrou wrote: > >> The merge here is mostly automatic. In fact, if the RM doesn't change > >> his/her clone at all, the merge is "null", even if devel repository has > >> evolved a lot in the meantime. > > > > By merge I meant the cherry picking operation itself ("svnmerge"). > > To be concrete, how many patches went inside 2.7.0 after cutting the > "rc1"?. Ideally, the answer should be "a handful". I don't think we are talking about branching after rc1 but after beta1, so that the feature branch can continue receive non-bugfix patches. That's quite many changesets to review. From steve at holdenweb.com Wed Feb 2 19:59:21 2011 From: steve at holdenweb.com (Steve Holden) Date: Wed, 2 Feb 2011 13:59:21 -0500 Subject: [python-committers] =?iso-8859-1?q?=5BPSF-Members=5D_Code_Simplic?= =?iso-8859-1?q?ity_=BB_Open_Source_Community=2C_Simplified?= In-Reply-To: <1296672429.3718.12.camel@localhost.localdomain> References: <4D495CBA.6040706@python.org> <20110202114702.133c59de@python.org> <4D4993C2.9080909@jcea.es> <1296668327.3718.8.camel@localhost.localdomain> <4D49A093.4020909@jcea.es> <1296671319.3718.9.camel@localhost.localdomain> <4D49A4D0.8070908@jcea.es> <1296672429.3718.12.camel@localhost.localdomain> Message-ID: On Feb 2, 2011, at 1:47 PM, Antoine Pitrou wrote: > Le mercredi 02 f?vrier 2011 ? 19:39 +0100, Jesus Cea a ?crit : >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 02/02/11 19:28, Antoine Pitrou wrote: >>>> The merge here is mostly automatic. In fact, if the RM doesn't change >>>> his/her clone at all, the merge is "null", even if devel repository has >>>> evolved a lot in the meantime. >>> >>> By merge I meant the cherry picking operation itself ("svnmerge"). >> >> To be concrete, how many patches went inside 2.7.0 after cutting the >> "rc1"?. Ideally, the answer should be "a handful". > > I don't think we are talking about branching after rc1 but after beta1, > so that the feature branch can continue receive non-bugfix patches. > That's quite many changesets to review. The paper I referenced talks about branching after tagging the release candidate. It seemed trivially obvious to me that you wouldn't want to branch while the feature set code is still being modified. That way the only things that (might) need merging would be late-stage and hopefully minor fixes from the released branch to the main trunk. With release candidates of sufficiently high quality there should be nothing to do. It seems so much simpler. To me, at least. But I could be missing something. regards Steve From solipsis at pitrou.net Wed Feb 2 20:10:11 2011 From: solipsis at pitrou.net (Antoine Pitrou) Date: Wed, 02 Feb 2011 20:10:11 +0100 Subject: [python-committers] =?iso-8859-1?q?=5BPSF-Members=5D_Code_Simplic?= =?iso-8859-1?q?ity_=BB_Open_Source_Community=2C_Simplified?= In-Reply-To: References: <4D495CBA.6040706@python.org> <20110202114702.133c59de@python.org> <4D4993C2.9080909@jcea.es> <1296668327.3718.8.camel@localhost.localdomain> <4D49A093.4020909@jcea.es> <1296671319.3718.9.camel@localhost.localdomain> <4D49A4D0.8070908@jcea.es> <1296672429.3718.12.camel@localhost.localdomain> Message-ID: <1296673811.3718.20.camel@localhost.localdomain> Le mercredi 02 f?vrier 2011 ? 13:59 -0500, Steve Holden a ?crit : > On Feb 2, 2011, at 1:47 PM, Antoine Pitrou wrote: > > > Le mercredi 02 f?vrier 2011 ? 19:39 +0100, Jesus Cea a ?crit : > >> -----BEGIN PGP SIGNED MESSAGE----- > >> Hash: SHA1 > >> > >> On 02/02/11 19:28, Antoine Pitrou wrote: > >>>> The merge here is mostly automatic. In fact, if the RM doesn't change > >>>> his/her clone at all, the merge is "null", even if devel repository has > >>>> evolved a lot in the meantime. > >>> > >>> By merge I meant the cherry picking operation itself ("svnmerge"). > >> > >> To be concrete, how many patches went inside 2.7.0 after cutting the > >> "rc1"?. Ideally, the answer should be "a handful". > > > > I don't think we are talking about branching after rc1 but after beta1, > > so that the feature branch can continue receive non-bugfix patches. > > That's quite many changesets to review. > The paper I referenced talks about branching after tagging the release > candidate. It seemed trivially obvious to me that you wouldn't want to > branch while the feature set code is still being modified. Ok, my bad. Perhaps they have different rules about what goes in between beta and rc, though? I don't know the Bugzilla project. > That way the only things that (might) need merging would be late-stage > and hopefully minor fixes from the released branch to the main trunk. > With release candidates of sufficiently high quality there should be > nothing to do. True. Regards Antoine. From jcea at jcea.es Wed Feb 2 21:18:59 2011 From: jcea at jcea.es (Jesus Cea) Date: Wed, 02 Feb 2011 21:18:59 +0100 Subject: [python-committers] =?iso-8859-15?q?=5BPSF-Members=5D_Code_Simpli?= =?iso-8859-15?q?city_=BB_Open_Source_Community=2C_Simplified?= In-Reply-To: <1296672429.3718.12.camel@localhost.localdomain> References: <4D495CBA.6040706@python.org> <20110202114702.133c59de@python.org> <4D4993C2.9080909@jcea.es> <1296668327.3718.8.camel@localhost.localdomain> <4D49A093.4020909@jcea.es> <1296671319.3718.9.camel@localhost.localdomain> <4D49A4D0.8070908@jcea.es> <1296672429.3718.12.camel@localhost.localdomain> Message-ID: <4D49BC33.3030706@jcea.es> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/02/11 19:47, Antoine Pitrou wrote: > I don't think we are talking about branching after rc1 but after beta1, > so that the feature branch can continue receive non-bugfix patches. > That's quite many changesets to review. A beta is like any other branch. The "canonical way" (TM) in mercurial is to write the patch for the "oldest" supported branch (in this case, the beta branch), and "up-port" it to the open devel repository. So, RM could say something like "beta branch is here. Commit there only things that MUST be in 3.3.0. For general development, commit to "py3k"". Anybody can merge from "beta" *TO* "py3k", for "up porting". The trick here is to patch the oldest supported version, and "up port" later, via mercurial merge. Just exactly the reverse of current workflow. - -- 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/ iQCVAwUBTUm8M5lgi5GaxT1NAQIgPAQAk4O26PQqlIi8S9S/3PVB09HinWTYJOhZ 0pD5ul6jkOO506ngZvjN6a652wsTq5CHscTnoyNHRRlq38Pn5Y6m4vZOYvIaH6P1 LGJ7b5bv97nrxSzHnfmMIyi7jGPbv7Jgv8otgov7UIJE3YeMtSjJrVZaG98Sv2rq Xdlv5DJwBb4= =f6/e -----END PGP SIGNATURE----- From barry at python.org Wed Feb 2 21:30:01 2011 From: barry at python.org (Barry Warsaw) Date: Wed, 2 Feb 2011 15:30:01 -0500 Subject: [python-committers] =?utf-8?q?=5BPSF-Members=5D_Code_Simplicity_?= =?utf-8?q?=C2=BB_Open_Source_Community=2C_Simplified?= In-Reply-To: <4D49BC33.3030706@jcea.es> References: <4D495CBA.6040706@python.org> <20110202114702.133c59de@python.org> <4D4993C2.9080909@jcea.es> <1296668327.3718.8.camel@localhost.localdomain> <4D49A093.4020909@jcea.es> <1296671319.3718.9.camel@localhost.localdomain> <4D49A4D0.8070908@jcea.es> <1296672429.3718.12.camel@localhost.localdomain> <4D49BC33.3030706@jcea.es> Message-ID: <20110202153001.527be580@python.org> On Feb 02, 2011, at 09:18 PM, Jesus Cea wrote: >On 02/02/11 19:47, Antoine Pitrou wrote: >> I don't think we are talking about branching after rc1 but after beta1, >> so that the feature branch can continue receive non-bugfix patches. >> That's quite many changesets to review. > >A beta is like any other branch. The "canonical way" (TM) in mercurial >is to write the patch for the "oldest" supported branch (in this case, >the beta branch), and "up-port" it to the open devel repository. > >So, RM could say something like "beta branch is here. Commit there only >things that MUST be in 3.3.0. For general development, commit to >"py3k"". Anybody can merge from "beta" *TO* "py3k", for "up porting". > >The trick here is to patch the oldest supported version, and "up port" >later, via mercurial merge. > >Just exactly the reverse of current workflow. And for good reason (IMO). It's often much less clear exactly how far back a specific patch should be committed when it's first being developed. It makes much more sense to me to fix a problem in the current development branch first, and then determine if, how, and where the patch should be back ported. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From ncoghlan at gmail.com Wed Feb 2 23:54:40 2011 From: ncoghlan at gmail.com (Nick Coghlan) Date: Thu, 3 Feb 2011 08:54:40 +1000 Subject: [python-committers] =?iso-8859-1?q?=5BPSF-Members=5D_Code_Simplic?= =?iso-8859-1?q?ity_=BB_Open_Source_Community=2C_Simplified?= In-Reply-To: <20110202153001.527be580@python.org> References: <4D495CBA.6040706@python.org> <20110202114702.133c59de@python.org> <4D4993C2.9080909@jcea.es> <1296668327.3718.8.camel@localhost.localdomain> <4D49A093.4020909@jcea.es> <1296671319.3718.9.camel@localhost.localdomain> <4D49A4D0.8070908@jcea.es> <1296672429.3718.12.camel@localhost.localdomain> <4D49BC33.3030706@jcea.es> <20110202153001.527be580@python.org> Message-ID: On Thu, Feb 3, 2011 at 6:30 AM, Barry Warsaw wrote: >>Just exactly the reverse of current workflow. > > And for good reason (IMO). ?It's often much less clear exactly how far back a > specific patch should be committed when it's first being developed. ?It makes > much more sense to me to fix a problem in the current development branch > first, and then determine if, how, and where the patch should be back ported. Indeed. Mainline is the only branch where we *know* most patches need to be applied. It also means that people can contribute while maintaining only a single checkout, rather than necessarily needing all active versions. I suspect this problem with the preferred DVCS workflow is going to cut fairly heavily into the number of bug fixes applied to the maintenance branches. Cheers, Nick. -- Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia From barry at python.org Thu Feb 3 00:16:12 2011 From: barry at python.org (Barry Warsaw) Date: Wed, 2 Feb 2011 18:16:12 -0500 Subject: [python-committers] =?utf-8?q?=5BPSF-Members=5D_Code_Simplicity_?= =?utf-8?q?=C2=BB_Open_Source_Community=2C_Simplified?= In-Reply-To: References: <4D495CBA.6040706@python.org> <20110202114702.133c59de@python.org> <4D4993C2.9080909@jcea.es> <1296668327.3718.8.camel@localhost.localdomain> <4D49A093.4020909@jcea.es> <1296671319.3718.9.camel@localhost.localdomain> <4D49A4D0.8070908@jcea.es> <1296672429.3718.12.camel@localhost.localdomain> <4D49BC33.3030706@jcea.es> <20110202153001.527be580@python.org> Message-ID: <20110202181612.11d54e3a@python.org> On Feb 03, 2011, at 08:54 AM, Nick Coghlan wrote: >I suspect this problem with the preferred DVCS workflow is going to >cut fairly heavily into the number of bug fixes applied to the >maintenance branches. I'd be really surprised if it *has* to be that way. Just how painful is it in Mercurial to apply to newest branch first and back port? -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From mal at egenix.com Thu Feb 3 00:27:45 2011 From: mal at egenix.com (M.-A. Lemburg) Date: Thu, 03 Feb 2011 00:27:45 +0100 Subject: [python-committers] =?iso-8859-1?q?=5BPSF-Members=5D_Code_Simplic?= =?iso-8859-1?q?ity_=BB_Open_Source_Community=2C_Simplified?= In-Reply-To: <20110202181612.11d54e3a@python.org> References: <4D495CBA.6040706@python.org> <20110202114702.133c59de@python.org> <4D4993C2.9080909@jcea.es> <1296668327.3718.8.camel@localhost.localdomain> <4D49A093.4020909@jcea.es> <1296671319.3718.9.camel@localhost.localdomain> <4D49A4D0.8070908@jcea.es> <1296672429.3718.12.camel@localhost.localdomain> <4D49BC33.3030706@jcea.es> <20110202153001.527be580@python.org> <20110202181612.11d54e3a@python.org> Message-ID: <4D49E871.70302@egenix.com> Barry Warsaw wrote: > On Feb 03, 2011, at 08:54 AM, Nick Coghlan wrote: > >> I suspect this problem with the preferred DVCS workflow is going to >> cut fairly heavily into the number of bug fixes applied to the >> maintenance branches. > > I'd be really surprised if it *has* to be that way. Just how painful is it in > Mercurial to apply to newest branch first and back port? Another question: Wouldn't it be easier to apply the patch to the mainline branch and the apply it to all release branches from there (and regardless of the order) ? I don't think "up-porting" patches works well for Python, since you usually have to adapt new patches to make them fit older releases (not the other way around). -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 03 2011) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ From ncoghlan at gmail.com Thu Feb 3 00:29:08 2011 From: ncoghlan at gmail.com (Nick Coghlan) Date: Thu, 3 Feb 2011 09:29:08 +1000 Subject: [python-committers] =?iso-8859-1?q?=5BPSF-Members=5D_Code_Simplic?= =?iso-8859-1?q?ity_=BB_Open_Source_Community=2C_Simplified?= In-Reply-To: <20110202181612.11d54e3a@python.org> References: <4D495CBA.6040706@python.org> <20110202114702.133c59de@python.org> <4D4993C2.9080909@jcea.es> <1296668327.3718.8.camel@localhost.localdomain> <4D49A093.4020909@jcea.es> <1296671319.3718.9.camel@localhost.localdomain> <4D49A4D0.8070908@jcea.es> <1296672429.3718.12.camel@localhost.localdomain> <4D49BC33.3030706@jcea.es> <20110202153001.527be580@python.org> <20110202181612.11d54e3a@python.org> Message-ID: On Thu, Feb 3, 2011 at 9:16 AM, Barry Warsaw wrote: > On Feb 03, 2011, at 08:54 AM, Nick Coghlan wrote: > >>I suspect this problem with the preferred DVCS workflow is going to >>cut fairly heavily into the number of bug fixes applied to the >>maintenance branches. > > I'd be really surprised if it *has* to be that way. ?Just how painful is it in > Mercurial to apply to newest branch first and back port? I have no idea. I just know that the first response from veteran hg users when asked how to implement our current workflow in Mercurial is "don't do that" (followed by reluctant explanations of tools you might use to do it, if you insisted on doing things "the wrong way"). Cheers, Nick. -- Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia From steve at holdenweb.com Thu Feb 3 00:35:33 2011 From: steve at holdenweb.com (Steve Holden) Date: Wed, 2 Feb 2011 18:35:33 -0500 Subject: [python-committers] =?iso-8859-1?q?=5BPSF-Members=5D_Code_Simplic?= =?iso-8859-1?q?ity_=BB_Open_Source_Community=2C_Simplified?= In-Reply-To: References: <4D495CBA.6040706@python.org> <20110202114702.133c59de@python.org> <4D4993C2.9080909@jcea.es> <1296668327.3718.8.camel@localhost.localdomain> <4D49A093.4020909@jcea.es> <1296671319.3718.9.camel@localhost.localdomain> <4D49A4D0.8070908@jcea.es> <1296672429.3718.12.camel@localhost.localdomain> <4D49BC33.3030706@jcea.es> <20110202153001.527be580@python.org> <20110202181612.11d54e3a@python.org> Message-ID: <1FD2B821-02AA-430D-BD20-88AD6C40B926@holdenweb.com> On Feb 2, 2011, at 6:29 PM, Nick Coghlan wrote: > On Thu, Feb 3, 2011 at 9:16 AM, Barry Warsaw wrote: >> On Feb 03, 2011, at 08:54 AM, Nick Coghlan wrote: >> >>> I suspect this problem with the preferred DVCS workflow is going to >>> cut fairly heavily into the number of bug fixes applied to the >>> maintenance branches. >> >> I'd be really surprised if it *has* to be that way. Just how painful is it in >> Mercurial to apply to newest branch first and back port? > > I have no idea. I just know that the first response from veteran hg > users when asked how to implement our current workflow in Mercurial is > "don't do that" (followed by reluctant explanations of tools you might > use to do it, if you insisted on doing things "the wrong way"). > Call me unadventurous, but i'd quite like to see how we get on ding things the *right* way first. regards Steve From ncoghlan at gmail.com Thu Feb 3 01:17:18 2011 From: ncoghlan at gmail.com (Nick Coghlan) Date: Thu, 3 Feb 2011 10:17:18 +1000 Subject: [python-committers] =?iso-8859-1?q?=5BPSF-Members=5D_Code_Simplic?= =?iso-8859-1?q?ity_=BB_Open_Source_Community=2C_Simplified?= In-Reply-To: <1FD2B821-02AA-430D-BD20-88AD6C40B926@holdenweb.com> References: <4D495CBA.6040706@python.org> <20110202114702.133c59de@python.org> <4D4993C2.9080909@jcea.es> <1296668327.3718.8.camel@localhost.localdomain> <4D49A093.4020909@jcea.es> <1296671319.3718.9.camel@localhost.localdomain> <4D49A4D0.8070908@jcea.es> <1296672429.3718.12.camel@localhost.localdomain> <4D49BC33.3030706@jcea.es> <20110202153001.527be580@python.org> <20110202181612.11d54e3a@python.org> <1FD2B821-02AA-430D-BD20-88AD6C40B926@holdenweb.com> Message-ID: On Thu, Feb 3, 2011 at 9:35 AM, Steve Holden wrote: > Call me unadventurous, but i'd quite like to see how we get on ding things the *right* way first. Call me pessimistic, but I'm predicting that quite a few people (including me) will continue their existing workflow, which is to work primarily on the main development branch. Without a reasonable backporting workflow, the end result will simply be stuff not being incorporated into maintenance branches. The backport approach allows the backport to be handled by someone other than the original committer, and defers the decision on whether or not a change is suitable for a maintenance branch until a more reasonable time in the process (i.e. after you have tried it out on the developmental branch first). The recommended Mercurial way asks people to make the decision of which branch to target *far* too early in the process. Cheers, Nick. -- Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia From ncoghlan at gmail.com Thu Feb 3 01:18:30 2011 From: ncoghlan at gmail.com (Nick Coghlan) Date: Thu, 3 Feb 2011 10:18:30 +1000 Subject: [python-committers] =?iso-8859-1?q?=5BPSF-Members=5D_Code_Simplic?= =?iso-8859-1?q?ity_=BB_Open_Source_Community=2C_Simplified?= In-Reply-To: References: <4D495CBA.6040706@python.org> <20110202114702.133c59de@python.org> <4D4993C2.9080909@jcea.es> <1296668327.3718.8.camel@localhost.localdomain> <4D49A093.4020909@jcea.es> <1296671319.3718.9.camel@localhost.localdomain> <4D49A4D0.8070908@jcea.es> <1296672429.3718.12.camel@localhost.localdomain> <4D49BC33.3030706@jcea.es> <20110202153001.527be580@python.org> <20110202181612.11d54e3a@python.org> <1FD2B821-02AA-430D-BD20-88AD6C40B926@holdenweb.com> Message-ID: (I should note that I don't consider this a dealbreaker for the switch to Mercurial - I'm just predicting a drop in maintenance patches for an extended period of time after the switch) Cheers, Nick. -- Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia From mfoord at python.org Thu Feb 3 01:22:05 2011 From: mfoord at python.org (Michael Foord) Date: Thu, 03 Feb 2011 00:22:05 +0000 Subject: [python-committers] =?iso-8859-1?q?=5BPSF-Members=5D_Code_Simplic?= =?iso-8859-1?q?ity_=BB_Open_Source_Community=2C_Simplified?= In-Reply-To: <1FD2B821-02AA-430D-BD20-88AD6C40B926@holdenweb.com> References: <4D495CBA.6040706@python.org> <20110202114702.133c59de@python.org> <4D4993C2.9080909@jcea.es> <1296668327.3718.8.camel@localhost.localdomain> <4D49A093.4020909@jcea.es> <1296671319.3718.9.camel@localhost.localdomain> <4D49A4D0.8070908@jcea.es> <1296672429.3718.12.camel@localhost.localdomain> <4D49BC33.3030706@jcea.es> <20110202153001.527be580@python.org> <20110202181612.11d54e3a@python.org> <1FD2B821-02AA-430D-BD20-88AD6C40B926@holdenweb.com> Message-ID: <4D49F52D.7070705@python.org> On 02/02/2011 23:35, Steve Holden wrote: > On Feb 2, 2011, at 6:29 PM, Nick Coghlan wrote: > >> On Thu, Feb 3, 2011 at 9:16 AM, Barry Warsaw wrote: >>> On Feb 03, 2011, at 08:54 AM, Nick Coghlan wrote: >>> >>>> I suspect this problem with the preferred DVCS workflow is going to >>>> cut fairly heavily into the number of bug fixes applied to the >>>> maintenance branches. >>> I'd be really surprised if it *has* to be that way. Just how painful is it in >>> Mercurial to apply to newest branch first and back port? >> I have no idea. I just know that the first response from veteran hg >> users when asked how to implement our current workflow in Mercurial is >> "don't do that" (followed by reluctant explanations of tools you might >> use to do it, if you insisted on doing things "the wrong way"). >> > Call me unadventurous, but i'd quite like to see how we get on ding things the *right* way first. > Well, I'm with Nick. Doing development on main and backporting *some* fixes is the right way for a development process. Michael > regards > Steve > > _______________________________________________ > python-committers mailing list > python-committers at python.org > http://mail.python.org/mailman/listinfo/python-committers -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html From jcea at jcea.es Thu Feb 3 01:37:33 2011 From: jcea at jcea.es (Jesus Cea) Date: Thu, 03 Feb 2011 01:37:33 +0100 Subject: [python-committers] =?iso-8859-15?q?=5BPSF-Members=5D_Code_Simpli?= =?iso-8859-15?q?city_=BB_Open_Source_Community=2C_Simplified?= In-Reply-To: <20110202153001.527be580@python.org> References: <4D495CBA.6040706@python.org> <20110202114702.133c59de@python.org> <4D4993C2.9080909@jcea.es> <1296668327.3718.8.camel@localhost.localdomain> <4D49A093.4020909@jcea.es> <1296671319.3718.9.camel@localhost.localdomain> <4D49A4D0.8070908@jcea.es> <1296672429.3718.12.camel@localhost.localdomain> <4D49BC33.3030706@jcea.es> <20110202153001.527be580@python.org> Message-ID: <4D49F8CD.90807@jcea.es> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/02/11 21:30, Barry Warsaw wrote: >> Just exactly the reverse of current workflow. > > And for good reason (IMO). It's often much less clear exactly how far back a > specific patch should be committed when it's first being developed. It makes > much more sense to me to fix a problem in the current development branch > first, and then determine if, how, and where the patch should be back ported. While I do agree with your point, when I take over a bug I test all supported versions to see which ones are buggy. Now you can choose to patch the latest and backport, or to patch the oldest and up-port. It is a choice. Mercurial is designed for up-porting. In fact, "up-porting" is usually better, because you don't have to think if you must downport or not. Versi?n "n+1" is always a superset of versi?n "n". So you "up-port" *ALWAYS*, automatically (mostly) via merge. If you choose the backporting way, you must take a decision about what to backport, for every single changeset. And god forbids you forget something in the process... I agree you have a point when you write a new functionality for the latest version and LATER somebody decides that a particular changeset must be backported. Or a fix not planed for old versions is re-scheduled. Would be very nice if the HG cherrypick extension would be more clever. Of if mercurial would recognize that a patch is already manually committed in both lines, and cope with that gracefully when merging. I am sure we are not alone with these issues, and I hope somebody is actually doing something about it. - -- 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/ iQCVAwUBTUn4zZlgi5GaxT1NAQLitQP/cWcs8zuR/bsEkLLzM0BKLKnvt+U/5EI9 EGfqTz+SOkB9g6Yvrh35r5LcyXREQGJz9jtvOQFo+6L5UOlhpDWDwBiyFW37sdzi SVrnzsog63DqAOpGVrOqwSV+0/pwgl7Kst5z9w+i42PD/atZsq2z31ze2qWP4QNM nvoR2K8HSSc= =cQ6Z -----END PGP SIGNATURE----- From alexander.belopolsky at gmail.com Thu Feb 3 01:44:44 2011 From: alexander.belopolsky at gmail.com (Alexander Belopolsky) Date: Wed, 2 Feb 2011 19:44:44 -0500 Subject: [python-committers] =?iso-8859-1?q?=5BPSF-Members=5D_Code_Simplic?= =?iso-8859-1?q?ity_=BB_Open_Source_Community=2C_Simplified?= In-Reply-To: <4D49F52D.7070705@python.org> References: <4D495CBA.6040706@python.org> <20110202114702.133c59de@python.org> <4D4993C2.9080909@jcea.es> <1296668327.3718.8.camel@localhost.localdomain> <4D49A093.4020909@jcea.es> <1296671319.3718.9.camel@localhost.localdomain> <4D49A4D0.8070908@jcea.es> <1296672429.3718.12.camel@localhost.localdomain> <4D49BC33.3030706@jcea.es> <20110202153001.527be580@python.org> <20110202181612.11d54e3a@python.org> <1FD2B821-02AA-430D-BD20-88AD6C40B926@holdenweb.com> <4D49F52D.7070705@python.org> Message-ID: On Wed, Feb 2, 2011 at 7:22 PM, Michael Foord wrote: > On 02/02/2011 23:35, Steve Holden wrote: >> >> On Feb 2, 2011, at 6:29 PM, Nick Coghlan wrote: >> >>> On Thu, Feb 3, 2011 at 9:16 AM, Barry Warsaw ?wrote: >>>> >>>> On Feb 03, 2011, at 08:54 AM, Nick Coghlan wrote: >>>> >>>>> I suspect this problem with the preferred DVCS workflow is going to >>>>> cut fairly heavily into the number of bug fixes applied to the >>>>> maintenance branches. >>>> >>>> I'd be really surprised if it *has* to be that way. ?Just how painful is >>>> it in >>>> Mercurial to apply to newest branch first and back port? >>> >>> I have no idea. I just know that the first response from veteran hg >>> users when asked how to implement our current workflow in Mercurial is >>> "don't do that" (followed by reluctant explanations of tools you might >>> use to do it, if you insisted on doing things "the wrong way"). >>> >> Call me unadventurous, but i'd quite like to see how we get on ding things >> the *right* way first. >> Call me naive, but isn't the planned hg workflow described in the PEP? http://www.python.org/dev/peps/pep-0385/#proposed-workflow No, I have not read it. :-) From g.brandl at gmx.net Thu Feb 3 08:58:10 2011 From: g.brandl at gmx.net (Georg Brandl) Date: Thu, 03 Feb 2011 08:58:10 +0100 Subject: [python-committers] =?iso-8859-1?q?=5BPSF-Members=5D_Code_Simplic?= =?iso-8859-1?q?ity_=BB_Open_Source_Community=2C_Simplified?= In-Reply-To: <20110202114702.133c59de@python.org> References: <4D495CBA.6040706@python.org> <20110202114702.133c59de@python.org> Message-ID: Am 02.02.2011 17:47, schrieb Barry Warsaw: > On Feb 02, 2011, at 01:31 PM, Michael Foord wrote: > >>One issue it raises is the difficulties caused by freezing the trunk for >>releases. Instead they advocate creating the release branch at the point of >>the release candidate instead of freezing trunk. There are issues I >>currently *can't* work on because trunk is frozen and would personally prefer >>to see us use the branch-on-release-candidate process. > > This is one of the primary problems solved by a dvcs. Exactly. This is why I didn't do it that way it during the 3.2 releases; I was always waiting for the hg switch to happen, and until then I thought it best not to change the process. Georg From g.brandl at gmx.net Thu Feb 3 09:01:03 2011 From: g.brandl at gmx.net (Georg Brandl) Date: Thu, 03 Feb 2011 09:01:03 +0100 Subject: [python-committers] =?utf-8?q?=5BPSF-Members=5D_Code_Simplicity_?= =?utf-8?q?=C2=BB_Open_Source_Community=2C_Simplified?= In-Reply-To: <1296672429.3718.12.camel@localhost.localdomain> References: <4D495CBA.6040706@python.org> <20110202114702.133c59de@python.org> <4D4993C2.9080909@jcea.es> <1296668327.3718.8.camel@localhost.localdomain> <4D49A093.4020909@jcea.es> <1296671319.3718.9.camel@localhost.localdomain> <4D49A4D0.8070908@jcea.es> <1296672429.3718.12.camel@localhost.localdomain> Message-ID: Am 02.02.2011 19:47, schrieb Antoine Pitrou: > Le mercredi 02 f?vrier 2011 ? 19:39 +0100, Jesus Cea a ?crit : >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 02/02/11 19:28, Antoine Pitrou wrote: >> >> The merge here is mostly automatic. In fact, if the RM doesn't change >> >> his/her clone at all, the merge is "null", even if devel repository has >> >> evolved a lot in the meantime. >> > >> > By merge I meant the cherry picking operation itself ("svnmerge"). >> >> To be concrete, how many patches went inside 2.7.0 after cutting the >> "rc1"?. Ideally, the answer should be "a handful". > > I don't think we are talking about branching after rc1 but after beta1, > so that the feature branch can continue receive non-bugfix patches. > That's quite many changesets to review. I don't think branching off at beta1 is helpful. Developers will happily continue adding features to trunk (because that's what's fun, isn't it), and not care much about the release branch. Obviously we want the opposite, and we want them to concentrate on bug fixing. Georg From g.brandl at gmx.net Thu Feb 3 09:05:43 2011 From: g.brandl at gmx.net (Georg Brandl) Date: Thu, 03 Feb 2011 09:05:43 +0100 Subject: [python-committers] =?iso-8859-15?q?=5BPSF-Members=5D_Code_Simpli?= =?iso-8859-15?q?city_=BB_Open_Source_Community=2C_Simplified?= In-Reply-To: <4D49F8CD.90807@jcea.es> References: <4D495CBA.6040706@python.org> <20110202114702.133c59de@python.org> <4D4993C2.9080909@jcea.es> <1296668327.3718.8.camel@localhost.localdomain> <4D49A093.4020909@jcea.es> <1296671319.3718.9.camel@localhost.localdomain> <4D49A4D0.8070908@jcea.es> <1296672429.3718.12.camel@localhost.localdomain> <4D49BC33.3030706@jcea.es> <20110202153001.527be580@python.org> <4D49F8CD.90807@jcea.es> Message-ID: Am 03.02.2011 01:37, schrieb Jesus Cea: > On 02/02/11 21:30, Barry Warsaw wrote: >>> Just exactly the reverse of current workflow. > >> And for good reason (IMO). It's often much less clear exactly how far back a >> specific patch should be committed when it's first being developed. It makes >> much more sense to me to fix a problem in the current development branch >> first, and then determine if, how, and where the patch should be back ported. > > While I do agree with your point, when I take over a bug I test all > supported versions to see which ones are buggy. Now you can choose to > patch the latest and backport, or to patch the oldest and up-port. It is > a choice. Mercurial is designed for up-porting. > > In fact, "up-porting" is usually better, because you don't have to think > if you must downport or not. Versi?n "n+1" is always a superset of > versi?n "n". So you "up-port" *ALWAYS*, automatically (mostly) via merge. > > If you choose the backporting way, you must take a decision about what > to backport, for every single changeset. And god forbids you forget > something in the process... That is the biggest problem. If we do adopt the backporting approach (which I dislike as well), I will continue work on my extended transplant extension that tracks backported changesets and supports blocking, as I think it will be essential to have something like svnmerge in that case. > I agree you have a point when you write a new functionality for the > latest version and LATER somebody decides that a particular changeset > must be backported. Or a fix not planed for old versions is re-scheduled. > > Would be very nice if the HG cherrypick extension would be more clever. > Of if mercurial would recognize that a patch is already manually > committed in both lines, and cope with that gracefully when merging. It does, if the diff is the same. If the diff is different, how should Mercurial know that the two changesets are the same patch? Georg From ncoghlan at gmail.com Thu Feb 3 13:04:41 2011 From: ncoghlan at gmail.com (Nick Coghlan) Date: Thu, 3 Feb 2011 22:04:41 +1000 Subject: [python-committers] =?iso-8859-1?q?=5BPSF-Members=5D_Code_Simplic?= =?iso-8859-1?q?ity_=BB_Open_Source_Community=2C_Simplified?= In-Reply-To: <4D49F8CD.90807@jcea.es> References: <4D495CBA.6040706@python.org> <20110202114702.133c59de@python.org> <4D4993C2.9080909@jcea.es> <1296668327.3718.8.camel@localhost.localdomain> <4D49A093.4020909@jcea.es> <1296671319.3718.9.camel@localhost.localdomain> <4D49A4D0.8070908@jcea.es> <1296672429.3718.12.camel@localhost.localdomain> <4D49BC33.3030706@jcea.es> <20110202153001.527be580@python.org> <4D49F8CD.90807@jcea.es> Message-ID: On Thu, Feb 3, 2011 at 10:37 AM, Jesus Cea wrote: > In fact, "up-porting" is usually better, because you don't have to think > if you must downport or not. Versi?n "n+1" is always a superset of > versi?n "n". So you "up-port" *ALWAYS*, automatically (mostly) via merge. As I said, I'm happy to roll with the proposed workflow as documented in the PEP, based on the advice from experts that Mercurial doesn't really suit our current work flow. I'm just noting that I expect the result will be fewer fixes in maintenance branches, since it is harder to divide the tasks of implementing a fix for the main line of development and applying that fix to the maintenance branches (unlike the way it often happens now). The worse possibility is that fixes may be applied to maintenance branches and not to the main line of development, leading to regressions after upgrades (since the associated tests wouldn't be forward ported either). Cheers, Nick. -- Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia From solipsis at pitrou.net Thu Feb 3 13:20:33 2011 From: solipsis at pitrou.net (Antoine Pitrou) Date: Thu, 03 Feb 2011 13:20:33 +0100 Subject: [python-committers] =?iso-8859-1?q?=5BPSF-Members=5D_Code_Simplic?= =?iso-8859-1?q?ity_=BB_Open_Source_Community=2C_Simplified?= In-Reply-To: References: <4D495CBA.6040706@python.org> <20110202114702.133c59de@python.org> <4D4993C2.9080909@jcea.es> <1296668327.3718.8.camel@localhost.localdomain> <4D49A093.4020909@jcea.es> <1296671319.3718.9.camel@localhost.localdomain> <4D49A4D0.8070908@jcea.es> <1296672429.3718.12.camel@localhost.localdomain> <4D49BC33.3030706@jcea.es> <20110202153001.527be580@python.org> <4D49F8CD.90807@jcea.es> Message-ID: <1296735633.3705.3.camel@localhost.localdomain> Le jeudi 03 f?vrier 2011 ? 22:04 +1000, Nick Coghlan a ?crit : > On Thu, Feb 3, 2011 at 10:37 AM, Jesus Cea wrote: > > In fact, "up-porting" is usually better, because you don't have to think > > if you must downport or not. Versi?n "n+1" is always a superset of > > versi?n "n". So you "up-port" *ALWAYS*, automatically (mostly) via merge. > > As I said, I'm happy to roll with the proposed workflow as documented > in the PEP, based on the advice from experts that Mercurial doesn't > really suit our current work flow. I'm just noting that I expect the > result will be fewer fixes in maintenance branches, since it is harder > to divide the tasks of implementing a fix for the main line of > development and applying that fix to the maintenance branches (unlike > the way it often happens now). I share the concern that it will make things harder for contributors (right now they only have to care about the feature branch). Also, the fact that we have several bugfix branches (2.x, 3.x, not counting security-only branches) makes the whole thing much fuzzier. Regards Antoine. From ncoghlan at gmail.com Thu Feb 3 15:07:07 2011 From: ncoghlan at gmail.com (Nick Coghlan) Date: Fri, 4 Feb 2011 00:07:07 +1000 Subject: [python-committers] =?iso-8859-1?q?=5BPSF-Members=5D_Code_Simplic?= =?iso-8859-1?q?ity_=BB_Open_Source_Community=2C_Simplified?= In-Reply-To: <1296735633.3705.3.camel@localhost.localdomain> References: <4D495CBA.6040706@python.org> <20110202114702.133c59de@python.org> <4D4993C2.9080909@jcea.es> <1296668327.3718.8.camel@localhost.localdomain> <4D49A093.4020909@jcea.es> <1296671319.3718.9.camel@localhost.localdomain> <4D49A4D0.8070908@jcea.es> <1296672429.3718.12.camel@localhost.localdomain> <4D49BC33.3030706@jcea.es> <20110202153001.527be580@python.org> <4D49F8CD.90807@jcea.es> <1296735633.3705.3.camel@localhost.localdomain> Message-ID: On Thu, Feb 3, 2011 at 10:20 PM, Antoine Pitrou wrote: > Le jeudi 03 f?vrier 2011 ? 22:04 +1000, Nick Coghlan a ?crit : >> On Thu, Feb 3, 2011 at 10:37 AM, Jesus Cea wrote: >> > In fact, "up-porting" is usually better, because you don't have to think >> > if you must downport or not. Versi?n "n+1" is always a superset of >> > versi?n "n". So you "up-port" *ALWAYS*, automatically (mostly) via merge. >> >> As I said, I'm happy to roll with the proposed workflow as documented >> in the PEP, based on the advice from experts that Mercurial doesn't >> really suit our current work flow. I'm just noting that I expect the >> result will be fewer fixes in maintenance branches, since it is harder >> to divide the tasks of implementing a fix for the main line of >> development and applying that fix to the maintenance branches (unlike >> the way it often happens now). > > I share the concern that it will make things harder for contributors > (right now they only have to care about the feature branch). One useful thing I have personally gotten out of this discussion is to identify the core reason I feel backporting is the "right" way to handle maintenance branches: it ensures that the *tests* that confirm a bug has been fixed are always applied to the *latest* branch first. This means that there should never be regressions of tested bug fixes, even after a major version upgrade. When fixes and their associated tests are applied to the oldest branch first, the only thing ensuring the forward port isn't forgotten is manual review, thus opening the door to regressions following a major version upgrade. Cheers, Nick. -- Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia From barry at python.org Thu Feb 3 22:23:35 2011 From: barry at python.org (Barry Warsaw) Date: Thu, 3 Feb 2011 16:23:35 -0500 Subject: [python-committers] =?utf-8?q?=5BPSF-Members=5D_Code_Simplicity_?= =?utf-8?q?=C2=BB_Open_Source_Community=2C_Simplified?= In-Reply-To: References: <4D495CBA.6040706@python.org> <20110202114702.133c59de@python.org> <4D4993C2.9080909@jcea.es> <1296668327.3718.8.camel@localhost.localdomain> <4D49A093.4020909@jcea.es> <1296671319.3718.9.camel@localhost.localdomain> <4D49A4D0.8070908@jcea.es> <1296672429.3718.12.camel@localhost.localdomain> Message-ID: <20110203162335.1d8817f7@python.org> On Feb 03, 2011, at 09:01 AM, Georg Brandl wrote: >I don't think branching off at beta1 is helpful. Developers will happily >continue adding features to trunk (because that's what's fun, isn't it), >and not care much about the release branch. Obviously we want the opposite, >and we want them to concentrate on bug fixing. Aside from when we branch for the next release, I think we can still impose trunk freezes when we feel we need them (either by convention or technology). This will prevent folks from *landing* new features on the trunk, but it will not prevent folks from *developing* new features, and even publishing, reviewing and sharing them. That's a big advantage over a centralized vcs like Subversion. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From barry at python.org Thu Feb 3 22:36:58 2011 From: barry at python.org (Barry Warsaw) Date: Thu, 3 Feb 2011 16:36:58 -0500 Subject: [python-committers] =?utf-8?q?=5BPSF-Members=5D_Code_Simplicity_?= =?utf-8?q?=C2=BB_Open_Source_Community=2C_Simplified?= In-Reply-To: References: <4D495CBA.6040706@python.org> <20110202114702.133c59de@python.org> Message-ID: <20110203163658.479d1073@python.org> On Feb 03, 2011, at 08:58 AM, Georg Brandl wrote: >Exactly. This is why I didn't do it that way it during the 3.2 releases; I >was always waiting for the hg switch to happen, and until then I thought it >best not to change the process. Smart man. :) We have a perfect storm approaching for the migration though. 3.2 will be released very soon so we have a natural cut-over point. The sprints will see most of the stakeholders in physical proximity to work together to make it happen. We'll also have lots of non-committers around for some high bandwidth tutorials getting the new workflows evangelized. Seriously, if we can't leave Atlanta with the migration operational, we should just admit defeat and stick with Subversion. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From solipsis at pitrou.net Thu Feb 3 22:39:13 2011 From: solipsis at pitrou.net (Antoine Pitrou) Date: Thu, 03 Feb 2011 22:39:13 +0100 Subject: [python-committers] =?iso-8859-1?q?=5BPSF-Members=5D_Code_Simplic?= =?iso-8859-1?q?ity_=BB_Open_Source_Community=2C_Simplified?= In-Reply-To: References: <4D495CBA.6040706@python.org> <20110202114702.133c59de@python.org> <4D4993C2.9080909@jcea.es> <1296668327.3718.8.camel@localhost.localdomain> <4D49A093.4020909@jcea.es> <1296671319.3718.9.camel@localhost.localdomain> <4D49A4D0.8070908@jcea.es> <1296672429.3718.12.camel@localhost.localdomain> Message-ID: <1296769153.3925.22.camel@localhost.localdomain> Le jeudi 03 f?vrier 2011 ? 09:01 +0100, Georg Brandl a ?crit : > I don't think branching off at beta1 is helpful. Developers will happily > continue adding features to trunk (because that's what's fun, isn't it), > and not care much about the release branch. Obviously we want the opposite, > and we want them to concentrate on bug fixing. I'm obviously not in a position to judge, but I find it interesting that you're arguing precisely for what the article says is better abandoned (according, apparently, to a numerical study of community activity): Graph analysis showed very clearly that every time we would freeze, the community would shrink drastically and it would take several months after we un-froze for the size of the community to recover. It happened uniformly, every single time we would freeze, over many years and many releases. [...] We addressed this issue by *never* freezing the trunk. [...] We are also doing feature development on the trunk *simultaneously* with those bug fixes. However, we?ve found that not only does the community expand more rapidly this way, but we also actually get our releases out more quickly than we used to. So it?s a win-win situation. (emphasis mine) Regards Antoine. From solipsis at pitrou.net Thu Feb 3 22:40:30 2011 From: solipsis at pitrou.net (Antoine Pitrou) Date: Thu, 03 Feb 2011 22:40:30 +0100 Subject: [python-committers] hg migration In-Reply-To: <20110203163658.479d1073@python.org> References: <4D495CBA.6040706@python.org> <20110202114702.133c59de@python.org> <20110203163658.479d1073@python.org> Message-ID: <1296769230.3925.23.camel@localhost.localdomain> Le jeudi 03 f?vrier 2011 ? 16:36 -0500, Barry Warsaw a ?crit : > On Feb 03, 2011, at 08:58 AM, Georg Brandl wrote: > > >Exactly. This is why I didn't do it that way it during the 3.2 releases; I > >was always waiting for the hg switch to happen, and until then I thought it > >best not to change the process. > > Smart man. :) > > We have a perfect storm approaching for the migration though. 3.2 will be > released very soon so we have a natural cut-over point. The sprints will see > most of the stakeholders in physical proximity to work together to make it > happen. We'll also have lots of non-committers around for some high bandwidth > tutorials getting the new workflows evangelized. > > Seriously, if we can't leave Atlanta with the migration operational, we should > just admit defeat and stick with Subversion. I'm not sure all of us will be *physically* in Atlanta - although there's no doubt we'll think about you :) From g.brandl at gmx.net Thu Feb 3 22:49:20 2011 From: g.brandl at gmx.net (Georg Brandl) Date: Thu, 03 Feb 2011 22:49:20 +0100 Subject: [python-committers] =?utf-8?q?=5BPSF-Members=5D_Code_Simplicity_?= =?utf-8?q?=C2=BB_Open_Source_Community=2C_Simplified?= In-Reply-To: <1296769153.3925.22.camel@localhost.localdomain> References: <4D495CBA.6040706@python.org> <20110202114702.133c59de@python.org> <4D4993C2.9080909@jcea.es> <1296668327.3718.8.camel@localhost.localdomain> <4D49A093.4020909@jcea.es> <1296671319.3718.9.camel@localhost.localdomain> <4D49A4D0.8070908@jcea.es> <1296672429.3718.12.camel@localhost.localdomain> <1296769153.3925.22.camel@localhost.localdomain> Message-ID: Am 03.02.2011 22:39, schrieb Antoine Pitrou: > Le jeudi 03 f?vrier 2011 ? 09:01 +0100, Georg Brandl a ?crit : >> I don't think branching off at beta1 is helpful. Developers will happily >> continue adding features to trunk (because that's what's fun, isn't it), >> and not care much about the release branch. Obviously we want the opposite, >> and we want them to concentrate on bug fixing. > > I'm obviously not in a position to judge, but I find it interesting that > you're arguing precisely for what the article says is better abandoned > (according, apparently, to a numerical study of community activity): Well, I hope that nobody thinks the article to be eternal truth that can't be argued about. I also haven't read it yet, so I'm just stating what I think. > Graph analysis showed very clearly that every time we would > freeze, the community would shrink drastically and it would take > several months after we un-froze for the size of the community > to recover. It happened uniformly, every single time we would > freeze, over many years and many releases. > > [...] > > We addressed this issue by *never* freezing the trunk. [...] We > are also doing feature development on the trunk *simultaneously* > with those bug fixes. However, we?ve found that not only does > the community expand more rapidly this way, but we also actually > get our releases out more quickly than we used to. So it?s a > win-win situation. It's unclear to me what is meant here by "the community would shrink". The amount of core developers certainly doesn't shrink during feature freezes, from what I've experienced. Those who are active before remain active, those who contribute sporadically don't really care. But as Barry says, this is all a bit different with DVCS, and everyone is welcome to develop new features in their own branches. I still think that -- even if only for workload reasons -- the official trunk should be closed to features during beta-rc phases. Georg From g.brandl at gmx.net Thu Feb 3 22:54:21 2011 From: g.brandl at gmx.net (Georg Brandl) Date: Thu, 03 Feb 2011 22:54:21 +0100 Subject: [python-committers] =?iso-8859-1?q?=5BPSF-Members=5D_Code_Simplic?= =?iso-8859-1?q?ity_=BB_Open_Source_Community=2C_Simplified?= In-Reply-To: <20110203163658.479d1073@python.org> References: <4D495CBA.6040706@python.org> <20110202114702.133c59de@python.org> <20110203163658.479d1073@python.org> Message-ID: Am 03.02.2011 22:36, schrieb Barry Warsaw: > On Feb 03, 2011, at 08:58 AM, Georg Brandl wrote: > >>Exactly. This is why I didn't do it that way it during the 3.2 releases; I >>was always waiting for the hg switch to happen, and until then I thought it >>best not to change the process. > > Smart man. :) > > We have a perfect storm approaching for the migration though. 3.2 will be > released very soon so we have a natural cut-over point. The sprints will see > most of the stakeholders in physical proximity to work together to make it > happen. We'll also have lots of non-committers around for some high bandwidth > tutorials getting the new workflows evangelized. I'm still hoping to get the conversion done *before* PyCon, so that everyone can already get familiar with the new system, in order to be productive at the sprints. But of course, I'm also counting on PyCon sprints as the "last line of defence" should all other attempts fail. > Seriously, if we can't leave Atlanta with the migration operational, we should > just admit defeat and stick with Subversion. Hah! I don't believe a word you say about sticking with Subversion. I think you're just silently waiting for an occasion to uncover the ready and polished bzr repositories... Georg From barry at python.org Thu Feb 3 22:55:44 2011 From: barry at python.org (Barry Warsaw) Date: Thu, 3 Feb 2011 16:55:44 -0500 Subject: [python-committers] hg migration In-Reply-To: <1296769230.3925.23.camel@localhost.localdomain> References: <4D495CBA.6040706@python.org> <20110202114702.133c59de@python.org> <20110203163658.479d1073@python.org> <1296769230.3925.23.camel@localhost.localdomain> Message-ID: <20110203165544.7e86aba1@python.org> On Feb 03, 2011, at 10:40 PM, Antoine Pitrou wrote: >I'm not sure all of us will be *physically* in Atlanta - although >there's no doubt we'll think about you :) I guess that means you won't be there? Bummer! -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From barry at python.org Thu Feb 3 23:16:37 2011 From: barry at python.org (Barry Warsaw) Date: Thu, 3 Feb 2011 17:16:37 -0500 Subject: [python-committers] =?utf-8?q?=5BPSF-Members=5D_Code_Simplicity_?= =?utf-8?q?=C2=BB_Open_Source_Community=2C_Simplified?= In-Reply-To: References: <4D495CBA.6040706@python.org> <20110202114702.133c59de@python.org> <20110203163658.479d1073@python.org> Message-ID: <20110203171637.0bb5e68d@python.org> On Feb 03, 2011, at 10:54 PM, Georg Brandl wrote: >I'm still hoping to get the conversion done *before* PyCon, so that everyone >can already get familiar with the new system, in order to be productive at the >sprints. But of course, I'm also counting on PyCon sprints as the "last line >of defence" should all other attempts fail. That would be awesome. >> Seriously, if we can't leave Atlanta with the migration operational, we >> should just admit defeat and stick with Subversion. > >Hah! I don't believe a word you say about sticking with Subversion. I think >you're just silently waiting for an occasion to uncover the ready and polished >bzr repositories... No comment. :) But seriously though, if we can get to hg before pycon, that will be great. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From jcea at jcea.es Fri Feb 4 04:10:32 2011 From: jcea at jcea.es (Jesus Cea) Date: Fri, 04 Feb 2011 04:10:32 +0100 Subject: [python-committers] =?iso-8859-15?q?=5BPSF-Members=5D_Code_Simpli?= =?iso-8859-15?q?city_=BB_Open_Source_Community=2C_Simplified?= In-Reply-To: References: <4D495CBA.6040706@python.org> <20110202114702.133c59de@python.org> <4D4993C2.9080909@jcea.es> <1296668327.3718.8.camel@localhost.localdomain> <4D49A093.4020909@jcea.es> <1296671319.3718.9.camel@localhost.localdomain> <4D49A4D0.8070908@jcea.es> <1296672429.3718.12.camel@localhost.localdomain> <4D49BC33.3030706@jcea.es> <20110202153001.527be580@python.org> <4D49F8CD.90807@jcea.es> Message-ID: <4D4B6E28.4010209@jcea.es> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/02/11 13:04, Nick Coghlan wrote: > On Thu, Feb 3, 2011 at 10:37 AM, Jesus Cea wrote: >> In fact, "up-porting" is usually better, because you don't have to think >> if you must downport or not. Versi?n "n+1" is always a superset of >> versi?n "n". So you "up-port" *ALWAYS*, automatically (mostly) via merge. > > As I said, I'm happy to roll with the proposed workflow as documented > in the PEP, based on the advice from experts that Mercurial doesn't > really suit our current work flow. I'm just noting that I expect the > result will be fewer fixes in maintenance branches, since it is harder > to divide the tasks of implementing a fix for the main line of > development and applying that fix to the maintenance branches (unlike > the way it often happens now). The problem now is that patches in the development branch are "forgotten" and not backported when appropiate, and nobody cares about "blocking" versions to "not backport". Now running "svnmerge" to do a real merge is very risky, because the "blocking" is not actually maintained. People uses "svnmerge" backporting patch by patch, manually. Automatic mode is a disaster, because nobody cares about "blocking" in "svnmerge". If we up-port, no patch is forgotten. The rule should be: "patches in n+1 are a SUPERSET of patches in n". With this rule, mercurial takes care of everything (a patch in n+1 can 'undo' a patch up-ported from n, if needed, keeping the rule). > The worse possibility is that fixes may be applied to maintenance > branches and not to the main line of development, leading to > regressions after upgrades (since the associated tests wouldn't be > forward ported either). That is not going to happen, because the mercurial merging between maintenance and development. This is the up-porting side, and merging should be automatic, you don't need to track anything, it is automagically done by mercurial. - -- 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/ iQCVAwUBTUtuJ5lgi5GaxT1NAQL9OwP/ScnQ6Ahcgqdu73H01VGe4XPeJv8mDGss DokVIB/UrqnhtdeE+ky1uWTVSvcdcsClWsLMHPtW1KyTqWuf83fT9J1UWdXm5ol9 +QR1I8Vgot/WYt0XJ4ktP8VbN3SsUJoT+cJfEdGYI9I3Cc5UrXVOuOwpioANjyvE 5EBgj6ro1QY= =slHU -----END PGP SIGNATURE----- From jcea at jcea.es Fri Feb 4 04:17:54 2011 From: jcea at jcea.es (Jesus Cea) Date: Fri, 04 Feb 2011 04:17:54 +0100 Subject: [python-committers] =?iso-8859-15?q?=5BPSF-Members=5D_Code_Simpli?= =?iso-8859-15?q?city_=BB_Open_Source_Community=2C_Simplified?= In-Reply-To: References: <4D495CBA.6040706@python.org> <20110202114702.133c59de@python.org> <4D4993C2.9080909@jcea.es> <1296668327.3718.8.camel@localhost.localdomain> <4D49A093.4020909@jcea.es> <1296671319.3718.9.camel@localhost.localdomain> <4D49A4D0.8070908@jcea.es> <1296672429.3718.12.camel@localhost.localdomain> <4D49BC33.3030706@jcea.es> <20110202153001.527be580@python.org> <4D49F8CD.90807@jcea.es> <1296735633.3705.3.camel@localhost.localdomain> Message-ID: <4D4B6FE2.8000808@jcea.es> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/02/11 15:07, Nick Coghlan wrote: > One useful thing I have personally gotten out of this discussion is to > identify the core reason I feel backporting is the "right" way to > handle maintenance branches: it ensures that the *tests* that confirm > a bug has been fixed are always applied to the *latest* branch first. > This means that there should never be regressions of tested bug fixes, > even after a major version upgrade. When fixes and their associated > tests are applied to the oldest branch first, the only thing ensuring > the forward port isn't forgotten is manual review, thus opening the > door to regressions following a major version upgrade. I am not sure I understand correctly. It is 4:15AM in Spain and I need to sleep badly. "Up-porting" CAN'T be forgotten because it is done "automagically" v?a mercurial merges. That is the point... - -- 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/ iQCVAwUBTUtv4plgi5GaxT1NAQIoBQP+OATzNITrX9vsDLW3o01vH2VSbi1EN0+5 x+oYWyu8vkg+IenrF7TS3nfo+P72EC7AzqTCA5Nlhcc/HUsayrc0D73DVuUpeyac 5BsSDq2AbRPkQcMd8fhaAKxsWL5p4NIiYsqGO2Odhfu8ZBO+KKIdJZbsU2//cZAi hmr7/4tbiE4= =xoOv -----END PGP SIGNATURE----- From ncoghlan at gmail.com Fri Feb 4 10:54:17 2011 From: ncoghlan at gmail.com (Nick Coghlan) Date: Fri, 4 Feb 2011 19:54:17 +1000 Subject: [python-committers] =?iso-8859-1?q?=5BPSF-Members=5D_Code_Simplic?= =?iso-8859-1?q?ity_=BB_Open_Source_Community=2C_Simplified?= In-Reply-To: <4D4B6FE2.8000808@jcea.es> References: <4D495CBA.6040706@python.org> <20110202114702.133c59de@python.org> <4D4993C2.9080909@jcea.es> <1296668327.3718.8.camel@localhost.localdomain> <4D49A093.4020909@jcea.es> <1296671319.3718.9.camel@localhost.localdomain> <4D49A4D0.8070908@jcea.es> <1296672429.3718.12.camel@localhost.localdomain> <4D49BC33.3030706@jcea.es> <20110202153001.527be580@python.org> <4D49F8CD.90807@jcea.es> <1296735633.3705.3.camel@localhost.localdomain> <4D4B6FE2.8000808@jcea.es> Message-ID: On Fri, Feb 4, 2011 at 1:17 PM, Jesus Cea wrote: > "Up-porting" CAN'T be forgotten because it is done "automagically" v?a > mercurial merges. That is the point... So developer A checks in a fix on 2.7, then gets sidetracked before forward porting it. When does it make it to 3.2 or the main development branch? Does everyone doing a forward merge from the maintenance branches run the risk of being landed with the task of doing a bulk merge of any forgotten forward ports before they can forward port the fix they're actually trying to implement? Cheers, Nick. -- Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia From mal at egenix.com Fri Feb 4 11:19:29 2011 From: mal at egenix.com (M.-A. Lemburg) Date: Fri, 04 Feb 2011 11:19:29 +0100 Subject: [python-committers] =?iso-8859-1?q?=5BPSF-Members=5D_Code_Simplic?= =?iso-8859-1?q?ity_=BB_Open_Source_Community=2C_Simplified?= In-Reply-To: <4D4B6E28.4010209@jcea.es> References: <4D495CBA.6040706@python.org> <20110202114702.133c59de@python.org> <4D4993C2.9080909@jcea.es> <1296668327.3718.8.camel@localhost.localdomain> <4D49A093.4020909@jcea.es> <1296671319.3718.9.camel@localhost.localdomain> <4D49A4D0.8070908@jcea.es> <1296672429.3718.12.camel@localhost.localdomain> <4D49BC33.3030706@jcea.es> <20110202153001.527be580@python.org> <4D49F8CD.90807@jcea.es> <4D4B6E28.4010209@jcea.es> Message-ID: <4D4BD2B1.9090307@egenix.com> Jesus Cea wrote: > On 03/02/11 13:04, Nick Coghlan wrote: >> On Thu, Feb 3, 2011 at 10:37 AM, Jesus Cea wrote: >>> In fact, "up-porting" is usually better, because you don't have to think >>> if you must downport or not. Versi?n "n+1" is always a superset of >>> versi?n "n". So you "up-port" *ALWAYS*, automatically (mostly) via merge. > >> As I said, I'm happy to roll with the proposed workflow as documented >> in the PEP, based on the advice from experts that Mercurial doesn't >> really suit our current work flow. I'm just noting that I expect the >> result will be fewer fixes in maintenance branches, since it is harder >> to divide the tasks of implementing a fix for the main line of >> development and applying that fix to the maintenance branches (unlike >> the way it often happens now). > > The problem now is that patches in the development branch are > "forgotten" and not backported when appropiate, and nobody cares about > "blocking" versions to "not backport". Now running "svnmerge" to do a > real merge is very risky, because the "blocking" is not actually > maintained. People uses "svnmerge" backporting patch by patch, manually. > Automatic mode is a disaster, because nobody cares about "blocking" in > "svnmerge". What's wrong about manually using svnmerge to backport those things that you actually do want to backport, rather than automatically merging back changes that you don't want to be backported ? Note that blocking checkins from backports to certain branches adds more work to the developers, than simply not relying on automatic merges at all. The reason is that many new features will not get backported, only fixes to problems will. > If we up-port, no patch is forgotten. The rule should be: "patches in > n+1 are a SUPERSET of patches in n". With this rule, mercurial takes > care of everything (a patch in n+1 can 'undo' a patch up-ported from n, > if needed, keeping the rule). Mercurial is still a mystery to me, so please bare with me... Is there a technical requirement for having to use this workflow: 1) Patch -> Branch 3.1 -> Branch 3.2 -> Mainline Why can't we use our current workflow: 2) Patch -> Mainline (optionally) -> Branch 3.2 (optionally) -> Branch 3.1 Or perhaps a slightly modified one (if it suits Mercurial better): 3) Patch -> Mainline (optionally) -> Branch 3.2 (optionally) -> Branch 3.1 (Legend to the diagrams: "->" means "merge patch into") Note that 2) could just as well be done like this: 2) Patch -> Mainline (optionally) -> Branch 3.1 (optionally) -> Branch 3.2 i.e. the order of the backports doesn't matter. I don't understand why the developers have to follow the tools and not the tools the developers. If a tool doesn't fit, it's the wrong tool, IMHO, unless there are good reasons for changing you workflow because it allows the *workflow* to improve (rather than just permitting you to work with a specific tool). In other words: change is good if it improves things, not if it only changes things :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 04 2011) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ From jcea at jcea.es Fri Feb 4 12:34:46 2011 From: jcea at jcea.es (Jesus Cea) Date: Fri, 04 Feb 2011 12:34:46 +0100 Subject: [python-committers] =?iso-8859-15?q?=5BPSF-Members=5D_Code_Simpli?= =?iso-8859-15?q?city_=BB_Open_Source_Community=2C_Simplified?= In-Reply-To: References: <4D495CBA.6040706@python.org> <20110202114702.133c59de@python.org> <4D4993C2.9080909@jcea.es> <1296668327.3718.8.camel@localhost.localdomain> <4D49A093.4020909@jcea.es> <1296671319.3718.9.camel@localhost.localdomain> <4D49A4D0.8070908@jcea.es> <1296672429.3718.12.camel@localhost.localdomain> <4D49BC33.3030706@jcea.es> <20110202153001.527be580@python.org> <4D49F8CD.90807@jcea.es> <1296735633.3705.3.camel@localhost.localdomain> <4D4B6FE2.8000808@jcea.es> Message-ID: <4D4BE456.40308@jcea.es> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/02/11 10:54, Nick Coghlan wrote: > On Fri, Feb 4, 2011 at 1:17 PM, Jesus Cea wrote: >> "Up-porting" CAN'T be forgotten because it is done "automagically" v?a >> mercurial merges. That is the point... > > So developer A checks in a fix on 2.7, then gets sidetracked before > forward porting it. > > When does it make it to 3.2 or the main development branch? > > Does everyone doing a forward merge from the maintenance branches run > the risk of being landed with the task of doing a bulk merge of any > forgotten forward ports before they can forward port the fix they're > actually trying to implement? This is a social problem, not a tech one. In my opinion, the "owner" of a fix can not be considered "done" until the patch is merged everywhere. In fact, if all the branches were in the same repository (I do not advocate it), you can check it at push time. Failing to comply would be as bad as committing a patch leaving all buildbots in red, or unbuildable code. - -- 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/ iQCVAwUBTUvkVplgi5GaxT1NAQJlUAQAlX4V4H4kpSNn95fjNJVMgR6SwJzsYrUe SGeIuqMM5TALMxx/f9t5V1rE10JEV7nzNyKtdSnYDVom3RJL0fDNyvIsxrSzvTJM jJB+sTnMDI5cJ7m767B/Fz+xQ2Z7dpdjBJ3e/dZbqJmas4GkXWW3W5fjkU41Kvqu mqhpleBPpuo= =Y27E -----END PGP SIGNATURE----- From victor.stinner at haypocalc.com Fri Feb 4 12:35:21 2011 From: victor.stinner at haypocalc.com (Victor Stinner) Date: Fri, 04 Feb 2011 12:35:21 +0100 Subject: [python-committers] =?iso-8859-1?q?=5BPSF-Members=5D_Code_Simplic?= =?iso-8859-1?q?ity_=BB_Open_Source_Community=2C_Simplified?= In-Reply-To: <20110202114702.133c59de@python.org> References: <4D495CBA.6040706@python.org> <20110202114702.133c59de@python.org> Message-ID: <1296819321.742.13.camel@marge> Le mercredi 02 f?vrier 2011 ? 11:47 -0500, Barry Warsaw a ?crit : > >One issue it raises is the difficulties caused by freezing the trunk for > >releases. Instead they advocate creating the release branch at the point of > >the release candidate instead of freezing trunk. There are issues I > >currently *can't* work on because trunk is frozen and would personally prefer > >to see us use the branch-on-release-candidate process. > > This is one of the primary problems solved by a dvcs. You can *always* and > *easily* work on new features, publish them for comment and review by others, > make continual progress regardless of the release status of the official > branches, and easily track movement in those official branches. I am already using a DVCS (git-svn) to work on Python, especially for my work on Unicode. It is just impossible to work on an huge change on trunk, it changes too fast. A SVN branch should be created or a DVCS tool should be used. I prefer DVCS over SVN: it's faster, it's easier to do small commits, merge/remove commits, etc. But my last problem is that I don't know how to publish my DVCS repository. It would be possible to host it at home, but I am to lazy to setup my server for that. The problem is also that the repository is huge (254 MB): publish it to Internet would be slow (I upload at 80 KB/sec) if I have to publish all files (and the history) the first time. It would be faster if I can fork an existing repository on a server (download is always faster than upload). I suppose that bitbucket will have a miror of Python (because they already proposed to host the official repository), and so it will be trivial to fork Python repository with just a bitbucket account. That will be great, because it will easier to share a branch, without having to be a Python core developer. We might also host forks on our server, but it implies to have to manager user accounts (with permissions), so do the same job than Bitbucket and other hosting websites. I don't use Mercurial miror today, because I cannot be used to commit into Subversion (if I'm wrong, please tell me how to do that!), and I'm also using git-svn to commit into Python. Victor From jcea at jcea.es Fri Feb 4 12:46:06 2011 From: jcea at jcea.es (Jesus Cea) Date: Fri, 04 Feb 2011 12:46:06 +0100 Subject: [python-committers] =?iso-8859-15?q?=5BPSF-Members=5D_Code_Simpli?= =?iso-8859-15?q?city_=BB_Open_Source_Community=2C_Simplified?= In-Reply-To: <4D4BD2B1.9090307@egenix.com> References: <4D495CBA.6040706@python.org> <20110202114702.133c59de@python.org> <4D4993C2.9080909@jcea.es> <1296668327.3718.8.camel@localhost.localdomain> <4D49A093.4020909@jcea.es> <1296671319.3718.9.camel@localhost.localdomain> <4D49A4D0.8070908@jcea.es> <1296672429.3718.12.camel@localhost.localdomain> <4D49BC33.3030706@jcea.es> <20110202153001.527be580@python.org> <4D49F8CD.90807@jcea.es> <4D4B6E28.4010209@jcea.es> <4D4BD2B1.9090307@egenix.com> Message-ID: <4D4BE6FE.6000008@jcea.es> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/02/11 11:19, M.-A. Lemburg wrote: > I don't understand why the developers have to follow the tools and > not the tools the developers. Well, the tool is designed for a particular workflow. If you do something else, you are fighting the tool and not taking advantage of its bigger strenght. I am advocating a particular workflow (reverse to current) because it is "natural" to mercurial and I find it sensible. That said, the fact is that current workflow can not be used comfy with current mercurial. That is a shameful limitation, I do agree. Some people is working in solving this limitations. But we have to consider if using a "non natural" workflow would alienate new coders familiar with "natural" mercurial workflow. Since one of the objectives of HG migration is to ease external contributions, doing thing "the right way" would help too. - -- 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/ iQCVAwUBTUvm/plgi5GaxT1NAQJwegP/f5N5PzUpwchEoh1ZeJGccuoGSVj7crTx 96hDNaQEcd9GG7V8IQ2+LXkjwF/HkCshkuyO2XMPFBVahzKOidlG5zEv4bAzDdvY lpiqo70sJYJt7doTwTxQx4v9lbuqYD0gHiv+3Sw06887gqyR05YqCdhcm8NgoNFg +YfLwmrwvu8= =iIIh -----END PGP SIGNATURE----- From victor.stinner at haypocalc.com Fri Feb 4 12:52:31 2011 From: victor.stinner at haypocalc.com (Victor Stinner) Date: Fri, 04 Feb 2011 12:52:31 +0100 Subject: [python-committers] Create a Mercurial repository with a branch per issue Message-ID: <1296820351.742.27.camel@marge> Hi, When a patch is attached to an issue, it is usually a patch for the last stable release or to trunk (2.7 or 3.2 trunk). The problem is that latter the patch doesn't apply to trunk anymore and the author have to update its patch. Sometimes, we ask to update a patch six months or one year after the creation of the patch. It is difficult to update big patches. It would be nice to create a branch for each issue (or each attached to an issue?), so we can test the patch in the branch and work on the patch without having to update the branch to trunk. If the patch has many versions, we keep the history of the changes, and at the end, it is easier to update the patch to trunk (e.g. rebase the branch). If the buildbots are able to checkout this branch: we can also test directly the patch and automatically post the result on the bug tracker. If it is a problem with security (a patch can execute arbitrary commands), this service may be reserved to core developer and the action would be manual. I hope that it will help to manage issues like "Regexp 2.7 (modifications to current re 2.2.2)" (issue #2636) which has ~73 files attached, most of them are new versions of the huge regex patch, on an history of 2 years... But I am not sure that the author of the 73 files will use Mercurial, so we should so something to simplify the usage of Mercurial in this case. I heard somewhere that some projects are already doing exactly that (create a branch per issue), but I don't remember which projects. We should learn from these projects. Victor (I prefer to discuss here because launching a possible flamewar on python-dev) From jcea at jcea.es Fri Feb 4 13:08:20 2011 From: jcea at jcea.es (Jesus Cea) Date: Fri, 04 Feb 2011 13:08:20 +0100 Subject: [python-committers] Create a Mercurial repository with a branch per issue In-Reply-To: <1296820351.742.27.camel@marge> References: <1296820351.742.27.camel@marge> Message-ID: <4D4BEC34.8080902@jcea.es> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/02/11 12:52, Victor Stinner wrote: > It would be nice to create a branch for each issue (or each attached to > an issue?) Change "branch" to "temporal clone". I support this, but implementation would be non trivial. I have missed forever about being able to check a fix before "officially" committing it. Your request would provide it. The problem is how to cope with security issues (a patch could execute arbitrary code in the buildbots) and how to change the buildbot reporting tools to NOT mix the results from different changeset. Currently when I try to identify the changeset that introduces a bug, and I do a bisection search, "everybody" can see that "experiment" in the public buildbots. That is not very sensible. For instance, you can see "red" buildbots, when those failing builds are not for HEAD and so, not relevant to anybody else. I can sympathize with each core developer just committing a patch and getting a rush because she sees red buildbots... not related to the patch. More, she has to wait until I finish before she can see results relevant to her. Rebasing is good before committing to the "real" repository, but anybody with a checkout clone will suffer. I guess the clone should be automatically destroyed as soon as the clone is merged back to the real repository. - -- 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/ iQCVAwUBTUvsNJlgi5GaxT1NAQI2xQP/U+zdReBfUe8Fu8AmFZMd+3To+mQsP9Oe IleFmkZ896Nz1CeNzSGCYM3vsytU+c4kd0CN7R+y1mFFGbuZ4oHySf96k/FAMnyH gO9RjnkRhKYi6BPKYi9nPYMwPd+t07F4bKPewFjlwbCa9EULtkQ2i2qyXl1ozMmn Th1aP/deTIw= =S8JV -----END PGP SIGNATURE----- From victor.stinner at haypocalc.com Fri Feb 4 13:15:42 2011 From: victor.stinner at haypocalc.com (Victor Stinner) Date: Fri, 04 Feb 2011 13:15:42 +0100 Subject: [python-committers] Create a Mercurial repository with a branch per issue In-Reply-To: <4D4BEC34.8080902@jcea.es> References: <1296820351.742.27.camel@marge> <4D4BEC34.8080902@jcea.es> Message-ID: <1296821742.1739.3.camel@marge> Le vendredi 04 f?vrier 2011 ? 13:08 +0100, Jesus Cea a ?crit : > I support this, but implementation would be non trivial. Yes, it is non trivial, but it would be helpful :-) > The problem is how to cope with security issues As I wrote: if security matters, only core developers should be able to run buildbots on such branch. > how to change the buildbot > reporting tools to NOT mix the results from different changeset. Hey, the buildbots are already able to run on a specific SVN branch, it is not something new. This service is already reserved to code developer... Hum, I am not sure... > That is not very sensible. For instance, you can > see "red" buildbots, when those failing builds are not for HEAD and so, > not relevant to anybody else. Yeah, it should be improved, but I can be fixed later. > Rebasing is good before committing to the "real" repository, but anybody > with a checkout clone will suffer. Why? Victor From solipsis at pitrou.net Fri Feb 4 13:25:54 2011 From: solipsis at pitrou.net (Antoine Pitrou) Date: Fri, 04 Feb 2011 13:25:54 +0100 Subject: [python-committers] =?iso-8859-1?q?=5BPSF-Members=5D_Code_Simplic?= =?iso-8859-1?q?ity_=BB_Open_Source_Community=2C_Simplified?= In-Reply-To: <4D4B6E28.4010209@jcea.es> References: <4D495CBA.6040706@python.org> <20110202114702.133c59de@python.org> <4D4993C2.9080909@jcea.es> <1296668327.3718.8.camel@localhost.localdomain> <4D49A093.4020909@jcea.es> <1296671319.3718.9.camel@localhost.localdomain> <4D49A4D0.8070908@jcea.es> <1296672429.3718.12.camel@localhost.localdomain> <4D49BC33.3030706@jcea.es> <20110202153001.527be580@python.org> <4D49F8CD.90807@jcea.es> <4D4B6E28.4010209@jcea.es> Message-ID: <1296822354.3774.3.camel@localhost.localdomain> > The problem now is that patches in the development branch are > "forgotten" and not backported when appropiate Sorry, do you have real examples of this? > If we up-port, no patch is forgotten. The rule should be: "patches in > n+1 are a SUPERSET of patches in n". With this rule, mercurial takes > care of everything (a patch in n+1 can 'undo' a patch up-ported from n, > if needed, keeping the rule). That's a theoretical and IMO na?ve point of view. In practice, there are many changesets that will not "up-port" cleanly and will need manual work. The work will not be much less than with down-porting. Regards Antoine. From jcea at jcea.es Fri Feb 4 13:50:32 2011 From: jcea at jcea.es (Jesus Cea) Date: Fri, 04 Feb 2011 13:50:32 +0100 Subject: [python-committers] Create a Mercurial repository with a branch per issue In-Reply-To: <1296821742.1739.3.camel@marge> References: <1296820351.742.27.camel@marge> <4D4BEC34.8080902@jcea.es> <1296821742.1739.3.camel@marge> Message-ID: <4D4BF618.2070100@jcea.es> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/02/11 13:15, Victor Stinner wrote: >> Rebasing is good before committing to the "real" repository, but anybody >> with a checkout clone will suffer. > > Why? Rebasing alters history. It messes with the "inmmutable" nature of history. Anybody with a clone must do it. If you don't do, when you resync, you will see a new head and your clone will be "different" of the one doing the rebase. That is, suppose: - -->1-->2-->3-->4 Now you rebase and collapse changesets 2-4, to get ready for merging with the real respository. You have: - -->1-->5 in your repository. Anybody that had cloned from you, when pull, will have in her repository: - -->1-->2-->3-->4 \ \-->5 Two heads, "different" repository views. If this second person has a patch in his own repository, and you try to merge back, you will get again the original changeset list, two heads, etc. As a general rule, rebase should be done ONLY in personal clones not shared by anybody. Or, in this particular case, a clone should be automatically destroyed after merging to main development line. - -- 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/ iQCVAwUBTUv2EJlgi5GaxT1NAQIrAQP/ZQAVu+AxIC5TGiU8MP6XfXihyNdA+qwL vmmSRLXb8jifAKtbbyk9z8Ucn6rzQW5vbeNJStvt4hpPDM224CwMDgUu2XFBums+ j8e7SEUvXmNleiwmwUsDAEqFYWRw3/rUmZIUvt/FWhy1lhrgOyIwFObeDMxjYdSG 1JFJrM5DHUo= =yB4X -----END PGP SIGNATURE----- From jcea at jcea.es Fri Feb 4 14:30:58 2011 From: jcea at jcea.es (Jesus Cea) Date: Fri, 04 Feb 2011 14:30:58 +0100 Subject: [python-committers] =?iso-8859-15?q?=5BPSF-Members=5D_Code_Simpli?= =?iso-8859-15?q?city_=BB_Open_Source_Community=2C_Simplified?= In-Reply-To: <1296822354.3774.3.camel@localhost.localdomain> References: <4D495CBA.6040706@python.org> <20110202114702.133c59de@python.org> <4D4993C2.9080909@jcea.es> <1296668327.3718.8.camel@localhost.localdomain> <4D49A093.4020909@jcea.es> <1296671319.3718.9.camel@localhost.localdomain> <4D49A4D0.8070908@jcea.es> <1296672429.3718.12.camel@localhost.localdomain> <4D49BC33.3030706@jcea.es> <20110202153001.527be580@python.org> <4D49F8CD.90807@jcea.es> <4D4B6E28.4010209@jcea.es> <1296822354.3774.3.camel@localhost.localdomain> Message-ID: <4D4BFF92.8020904@jcea.es> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/02/11 13:25, Antoine Pitrou wrote: > >> The problem now is that patches in the development branch are >> "forgotten" and not backported when appropiate > > Sorry, do you have real examples of this? None I can show just now :(. I do remember discussion about some patches not being backported because people were trying to speed up py3k. >> If we up-port, no patch is forgotten. The rule should be: "patches in >> n+1 are a SUPERSET of patches in n". With this rule, mercurial takes >> care of everything (a patch in n+1 can 'undo' a patch up-ported from n, >> if needed, keeping the rule). > > That's a theoretical and IMO na?ve point of view. In practice, there are > many changesets that will not "up-port" cleanly and will need manual > work. The work will not be much less than with down-porting. I don't understand how "backporting" is easy, and "upporting" is difficult. You have to potentially manually tweak in both cases. Let's see. We have these branches: 1. Old releases, still supported (security, critical fixes). These releases are mostly static. Any patch there would "naturally" need to be applied too in more modern branches. That is, "up porting". 2. Released and supported releases: These are bug fix only branches. Traffic should be low. Since only fixes go in, every changeset should be applied too to more modern branches. That is, "up porting". 3. Not yet, but about to be released branch. Currently this "freezes" the trunk, or patches are very restricted. For instance, "no new features". This status can be pretty lenghtly now, months. I suggest to "clone" the trunk here. This will be the beta/rc/final/maintenance clone. Trunk remains fully open. This clone has a restricting patch policy (no new features in the beginning, fixes only later). Any patch here, bug fix, documentation clean up, etc. should be "up ported" too to trunk. Trunk is open all the time. Some fellows said that this would disincentivate contributions to the beta branch. In fact, coders would love to see their fixes/code/whatever they do being released in the next python version, three months for now, instead in the n+1 version, two years away. So I guess people would rush to commit to the beta clone (just like now!). But coders with long term plans can keep working in the trunk, freely. For instance, new stdlib modules. The only issue in this plan would be trunk evolving so fast that up-porting changesets from the beta to trunk (merging) would be non automatic. The beta being a few months long would help. Anyway, we could have a social rule to "avoid" doing heavy incompatible work for a while, until the release. Anyway, we already have the issue now, because if trunk is wildy diverging, we already have issues when backporting from trunk to the maintenance branches. In fact this situation disincentivate "back porting", since it would be costly. If you "up port", you can't left behind any patch. My guess is that most coders would concentrate in the beta clone, because they want their work released as fast as possible, and people working in trunk would be guys adding new functionality. I bet that overlapping changes would be pretty rare, during the beta/rc time. Something to note is that mercurial merge is pretty clever, and can follow things like file renaming/moving, line number offset, etc. It is a "three way merge", far more powerful that simply trying to apply a patch to a file. Mercurial do a history evaluation and know how to modify your changeset to be applied cleanly, most of the time. For instance, if the file was modified in trunk to add a 2000 line patch, mercurial knows how to "offset" your changeset before trying to automatically apply. PS: When a branch moves to a *temporal* restricted commit state, a new clone should be created, for people to keep working in the new minor release. That is, we are now in 3.2.0 release candidate. Patching is very restricted. If we had a 3.2.0 release candidate clone, MUST SHIP changes would be in the 3.2.0rc repository, but patches planned for 3.2.1 would be being already being committed the clone. When 3.2.0 is released and the branch is marked as "maintenance", the 3.2.1 clone would merge into the 3.2 maintenance and destroyed. The point is... to never temporally freeze any repository. The only frozen repositories would be dead ones. - -- 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/ iQCVAwUBTUv/kplgi5GaxT1NAQLWHQQAhOlRmla8vfLFJekN7pa51rDex2aJ8a+X XtUucgBrzHjxvjCdlmMFexPvY52tq2/re4UkSso79ANzdn6B7wvaVLW+HZvcIrhF uWptP765gdgSIPb1bwuN8ToJDK77CjjXQvcO1gO50oTe6P+I6l703kwHWMC499al NA1x17si8xk= =4qaS -----END PGP SIGNATURE----- From ziade.tarek at gmail.com Fri Feb 4 14:31:19 2011 From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=) Date: Fri, 4 Feb 2011 14:31:19 +0100 Subject: [python-committers] Create a Mercurial repository with a branch per issue In-Reply-To: <4D4BF618.2070100@jcea.es> References: <1296820351.742.27.camel@marge> <4D4BEC34.8080902@jcea.es> <1296821742.1739.3.camel@marge> <4D4BF618.2070100@jcea.es> Message-ID: On Fri, Feb 4, 2011 at 1:50 PM, Jesus Cea wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 04/02/11 13:15, Victor Stinner wrote: >>> Rebasing is good before committing to the "real" repository, but anybody >>> with a checkout clone will suffer. >> >> Why? > > Rebasing alters history. It messes with the "inmmutable" nature of > history. Anybody with a clone must do it. If you don't do, when you > resync, you will see a new head and your clone will be "different" of > the one doing the rebase. > > That is, suppose: > > - -->1-->2-->3-->4 > > Now you rebase and collapse changesets 2-4, to get ready for merging > with the real respository. You have: > > - -->1-->5 > > in your repository. > > Anybody that had cloned from you, when pull, will have in her repository: > > - -->1-->2-->3-->4 > ? ?\ > ? ? \-->5 > > Two heads, "different" repository views. If this second person has a > patch in his own repository, and you try to merge back, you will get > again the original changeset list, two heads, etc. > > As a general rule, rebase should be done ONLY in personal clones not > shared by anybody. Or, in this particular case, a clone should be > automatically destroyed after merging to main development line. That's why I think it's much cleaner to work with mq to build a clean single-commit patch, even if a clone may be used for temporary states and sharing. We are experiencing merge hell right now in Distutils2, as the contributor list grows, because of the way people work with clones. We are polluting history with a lot of "merge" commits because it's the most simple way to work w/ mercurial. I don't want to fork this thread but I think we should set up a "mercurial good practice" guide somewhere for hg.python.org could be awesome, in particular since the number of indirect contributors is going to grow with Python under a DVCS Cheers Tarek -- Tarek Ziad? | http://ziade.org From jcea at jcea.es Fri Feb 4 14:48:57 2011 From: jcea at jcea.es (Jesus Cea) Date: Fri, 04 Feb 2011 14:48:57 +0100 Subject: [python-committers] Create a Mercurial repository with a branch per issue In-Reply-To: References: <1296820351.742.27.camel@marge> <4D4BEC34.8080902@jcea.es> <1296821742.1739.3.camel@marge> <4D4BF618.2070100@jcea.es> Message-ID: <4D4C03C9.5070308@jcea.es> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/02/11 14:31, Tarek Ziad? wrote: >> As a general rule, rebase should be done ONLY in personal clones not >> shared by anybody. Or, in this particular case, a clone should be >> automatically destroyed after merging to main development line. > > That's why I think it's much cleaner to work with mq to build a clean > single-commit patch, even if a clone may be used for temporary states > and sharing. Well, MQ are not easily shared. If you don't share your clone anyway, you can freely commit to it and then collapse all your changes via rebase, before pushing. > We are experiencing merge hell right now in Distutils2, as the > contributor list grows, because of the way people work with clones. We > are polluting history with a lot of "merge" commits because it's the > most simple way to work w/ mercurial. I have tendency to commit to my clones constantly. I can do 100 commits per day, in my private clone. When pushing to the main repository, you have the option to push all the tiny changesets, or collapse all of them via rebase. I am not sure what way is better. Keeping ALL the history would be interesting anyway, but most of my tiny commits would break the build (I commit everytime I stop for thinking, pee, whatever. It is like autosave in my text editor), so things like "bisect" would be difficult to use. And reviewing 200 stupid patches when patch n+20 undo buggy patch n+1, is not pleasant. This is a social issue. > I don't want to fork this thread but I think we should set up a > "mercurial good practice" guide somewhere for hg.python.org could be > awesome, in particular since the number of indirect contributors is > going to grow with Python under a DVCS +1. But first we need the mercurial switchover to be done and to get some first hand experience before writing down the best practices *wiki* :). - -- 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/ iQCVAwUBTUwDyZlgi5GaxT1NAQJGoAP/bvWOUNoc5DKfjt3K3T2uMes8A8Agsawr RlbQmsBhlPDeaye4oe5zBgue2xIguhtVazGjd5jC9SOBYHSIVMTlpabdxoFoUisO eili9X8zHwdEVDhmfg7Gp8BeGMwS7mOx35WEY96Xbsw1WtKbTSP8J4WyZwMC9TW0 ZDXdNqDo9mE= =Fdwj -----END PGP SIGNATURE----- From ziade.tarek at gmail.com Fri Feb 4 14:57:59 2011 From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=) Date: Fri, 4 Feb 2011 14:57:59 +0100 Subject: [python-committers] Create a Mercurial repository with a branch per issue In-Reply-To: <4D4C03C9.5070308@jcea.es> References: <1296820351.742.27.camel@marge> <4D4BEC34.8080902@jcea.es> <1296821742.1739.3.camel@marge> <4D4BF618.2070100@jcea.es> <4D4C03C9.5070308@jcea.es> Message-ID: On Fri, Feb 4, 2011 at 2:48 PM, Jesus Cea wrote: .. > I am not sure what way is better. Keeping ALL the history would be > interesting anyway, but most of my tiny commits would break the build (I > commit everytime I stop for thinking, pee, whatever. It is like autosave > in my text editor), so things like "bisect" would be difficult to use. > And reviewing 200 stupid patches when patch n+20 undo buggy patch n+1, > is not pleasant. > > This is a social issue. Let's take the use case of Python development since it's what we discuss here. You are building a patch and submit it to reviews (in roundup or in a clone or retvield etc). You get feedback and you refine the patch. I don't think you want to keep that history, e.g. "changing this and that in my patch after feedback from MrX about Y" The main line history is what counts imo, not the history of how your patch was built, refactored etc. before it got merged. >> I don't want to fork this thread but I think we should set up a >> "mercurial good practice" guide somewhere for hg.python.org could be >> awesome, in particular since the number of indirect contributors is >> going to grow with Python under a DVCS > > +1. But first we need the mercurial switchover to be done and to get > some first hand experience before writing down the best practices *wiki* :). I'd rather have a best practice guide *now* and refine it later. e.g. "how to contribute to python via mercurial." I think we have people here with a decent expertise of Mercurial that can come up w/ this, even if it's changed after. Cheers Tarek -- Tarek Ziad? | http://ziade.org From victor.stinner at haypocalc.com Fri Feb 4 15:26:59 2011 From: victor.stinner at haypocalc.com (Victor Stinner) Date: Fri, 04 Feb 2011 15:26:59 +0100 Subject: [python-committers] Create a Mercurial repository with a branch per issue In-Reply-To: <4D4C03C9.5070308@jcea.es> References: <1296820351.742.27.camel@marge> <4D4BEC34.8080902@jcea.es> <1296821742.1739.3.camel@marge> <4D4BF618.2070100@jcea.es> <4D4C03C9.5070308@jcea.es> Message-ID: <1296829619.1858.1.camel@marge> Le vendredi 04 f?vrier 2011 ? 14:48 +0100, Jesus Cea a ?crit : > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 04/02/11 14:31, Tarek Ziad? wrote: > >> As a general rule, rebase should be done ONLY in personal clones not > >> shared by anybody. Or, in this particular case, a clone should be > >> automatically destroyed after merging to main development line. > > > > That's why I think it's much cleaner to work with mq to build a clean > > single-commit patch, even if a clone may be used for temporary states > > and sharing. > > Well, MQ are not easily shared. If you don't share your clone anyway, > you can freely commit to it and then collapse all your changes via > rebase, before pushing. About rebase: I forgot to mention that I don't publish my repository, so I am free to rebase it as much as I want :-) Victor From rdmurray at bitdance.com Fri Feb 4 15:30:19 2011 From: rdmurray at bitdance.com (R. David Murray) Date: Fri, 04 Feb 2011 09:30:19 -0500 Subject: [python-committers] =?iso-8859-1?q?=5BPSF-Members=5D_Code_Simplic?= =?iso-8859-1?q?ity_=BB_Open_Source_Community=2C_Simplified?= In-Reply-To: <1296822354.3774.3.camel@localhost.localdomain> References: <4D495CBA.6040706@python.org> <20110202114702.133c59de@python.org> <4D4993C2.9080909@jcea.es> <1296668327.3718.8.camel@localhost.localdomain> <4D49A093.4020909@jcea.es> <1296671319.3718.9.camel@localhost.localdomain> <4D49A4D0.8070908@jcea.es> <1296672429.3718.12.camel@localhost.localdomain> <4D49BC33.3030706@jcea.es> <20110202153001.527be580@python.org> <4D49F8CD.90807@jcea.es> <4D4B6E28.4010209@jcea.es> <1296822354.3774.3.camel@localhost.localdomain> Message-ID: <20110204143019.5B3DB241BF5@kimball.webabinitio.net> On Fri, 04 Feb 2011 13:25:54 +0100, Antoine Pitrou wrote: > > The problem now is that patches in the development branch are > > "forgotten" and not backported when appropiate > > Sorry, do you have real examples of this? I can't point you at specific examples, but I remember reading issues where the comment was made that a fix had been "forgotten". Sometimes it gets into a point release, sometimes it gets forgotten until after the minor version goes into security mode. I think this happened most when people were relying on other people doing mass merges, when the mass merges stopped happening, but I'm not sure. > > If we up-port, no patch is forgotten. The rule should be: "patches in > > n+1 are a SUPERSET of patches in n". With this rule, mercurial takes > > care of everything (a patch in n+1 can 'undo' a patch up-ported from n, > > if needed, keeping the rule). > > That's a theoretical and IMO na??ve point of view. In practice, there are > many changesets that will not "up-port" cleanly and will need manual > work. The work will not be much less than with down-porting. As Nick pointed it, it is much worse to forget to forward port a patch than to forget to back port it. We have had a few of the former even with our current workflow, and it is really embarrassing when it happens[*]. -- R. David Murray www.bitdance.com [*] And I can reference you to one mistake, where the Mercurial-style workflow was used: at one point the version number of the email package was bumped in a release candidate branch but the bump wasn't forward ported to the mainline. From dirkjan at ochtman.nl Fri Feb 4 15:44:17 2011 From: dirkjan at ochtman.nl (Dirkjan Ochtman) Date: Fri, 4 Feb 2011 15:44:17 +0100 Subject: [python-committers] Create a Mercurial repository with a branch per issue In-Reply-To: References: <1296820351.742.27.camel@marge> <4D4BEC34.8080902@jcea.es> <1296821742.1739.3.camel@marge> <4D4BF618.2070100@jcea.es> Message-ID: On Fri, Feb 4, 2011 at 14:31, Tarek Ziad? wrote: > That's why I think it's much cleaner to work with mq to build a clean > single-commit patch, ?even if a clone may be used for temporary states > and sharing. > > We are experiencing merge hell right now in Distutils2, as the > contributor list grows, because of the way people work with clones. We > are polluting history with a lot of "merge" commits because it's the > most simple way to work w/ mercurial. Yeah, it seems like you might want to ask more people to use mq or rebase (either way works -- or just pull and update just before your commit). IMO people should always rebase locally before committing, so that merges aren't generally required for that. Only if their work has gone really stale (some large refactoring landed in the mean time) it might be worth it to explicitly record the merge. I think extra clones per issue could work for some larger issues that require lots of work, but I don't think the every-small-feature-on-a-branch model (as practiced in Twisted, IIRC) is particularly helpful. On the other hand, I do think it's helpful to publish changes as multiple commits (where the test suite passes at each separate stage of the larger change). Cheers, Dirkjan From steve at holdenweb.com Fri Feb 4 16:31:11 2011 From: steve at holdenweb.com (Steve Holden) Date: Fri, 4 Feb 2011 10:31:11 -0500 Subject: [python-committers] Create a Mercurial repository with a branch per issue In-Reply-To: References: <1296820351.742.27.camel@marge> <4D4BEC34.8080902@jcea.es> <1296821742.1739.3.camel@marge> <4D4BF618.2070100@jcea.es> Message-ID: <028691AA-A2CE-4C35-8BAB-C3A82C9DDC17@holdenweb.com> On Feb 4, 2011, at 9:44 AM, Dirkjan Ochtman wrote: > I think extra clones per issue could work for some larger issues that > require lots of work, but I don't think the > every-small-feature-on-a-branch model (as practiced in Twisted, IIRC) > is particularly helpful. On the other hand, I do think it's helpful to > publish changes as multiple commits (where the test suite passes at > each separate stage of the larger change). > +1 S From mal at egenix.com Fri Feb 4 16:35:21 2011 From: mal at egenix.com (M.-A. Lemburg) Date: Fri, 04 Feb 2011 16:35:21 +0100 Subject: [python-committers] Create a Mercurial repository with a branch per issue In-Reply-To: References: <1296820351.742.27.camel@marge> <4D4BEC34.8080902@jcea.es> <1296821742.1739.3.camel@marge> <4D4BF618.2070100@jcea.es> <4D4C03C9.5070308@jcea.es> Message-ID: <4D4C1CB9.6040203@egenix.com> Tarek Ziad? wrote: > You are building a patch and submit it to reviews (in roundup or in a > clone or retvield etc). You get feedback and you refine the patch. > > I don't think you want to keep that history, e.g. "changing this and > that in my patch after feedback from MrX about Y" > > The main line history is what counts imo, not the history of how your > patch was built, refactored etc. before it got merged. +1 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 04 2011) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ From ncoghlan at gmail.com Fri Feb 4 16:49:06 2011 From: ncoghlan at gmail.com (Nick Coghlan) Date: Sat, 5 Feb 2011 01:49:06 +1000 Subject: [python-committers] =?iso-8859-1?q?=5BPSF-Members=5D_Code_Simplic?= =?iso-8859-1?q?ity_=BB_Open_Source_Community=2C_Simplified?= In-Reply-To: <20110204143019.5B3DB241BF5@kimball.webabinitio.net> References: <4D495CBA.6040706@python.org> <20110202114702.133c59de@python.org> <4D4993C2.9080909@jcea.es> <1296668327.3718.8.camel@localhost.localdomain> <4D49A093.4020909@jcea.es> <1296671319.3718.9.camel@localhost.localdomain> <4D49A4D0.8070908@jcea.es> <1296672429.3718.12.camel@localhost.localdomain> <4D49BC33.3030706@jcea.es> <20110202153001.527be580@python.org> <4D49F8CD.90807@jcea.es> <4D4B6E28.4010209@jcea.es> <1296822354.3774.3.camel@localhost.localdomain> <20110204143019.5B3DB241BF5@kimball.webabinitio.net> Message-ID: On Sat, Feb 5, 2011 at 12:30 AM, R. David Murray wrote: >> That's a theoretical and IMO na?ve point of view. In practice, there are >> many changesets that will not "up-port" cleanly and will need manual >> work. The work will not be much less than with down-porting. > > As Nick pointed it, it is much worse to forget to forward port a patch > than to forget to back port it. ?We have had a few of the former even with > our current workflow, and it is really embarrassing when it happens[*]. On the other hand, if *any* forward port naturally picks up all the missed forward ports, then the Mercurial perspective starts to make more sense (especially if the merge is able to exploit the DAG in order to make fewer mistakes). I'd definitely like to see some specific guidance from the Mercurial veterans on how they handle developing against multiple branches, though. From the sound of it, there's going to be a lot more hopping around between branches for different activities once it goes live. Cheers, Nick. -- Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia From ncoghlan at gmail.com Fri Feb 4 16:56:17 2011 From: ncoghlan at gmail.com (Nick Coghlan) Date: Sat, 5 Feb 2011 01:56:17 +1000 Subject: [python-committers] Create a Mercurial repository with a branch per issue In-Reply-To: References: <1296820351.742.27.camel@marge> <4D4BEC34.8080902@jcea.es> <1296821742.1739.3.camel@marge> <4D4BF618.2070100@jcea.es> <4D4C03C9.5070308@jcea.es> Message-ID: On Fri, Feb 4, 2011 at 11:57 PM, Tarek Ziad? wrote: > I'd rather have a best practice guide *now* and refine it later. e.g. > "how to contribute to python via mercurial." > > I think we have people here with a decent expertise of Mercurial that > can come up w/ this, even if it's changed after. Yes, please. Having a best practices document *in advance* will help keep things productive, especially with the Pycon sprints coming up shortly after the anticipated switchover. Aside from the basics (how to checkout, how to generate a patch file), things I'd personally like advice on: - how best to work with multiple branches to support the forward porting model for bug fixing - how to clean a history ready for commit - how to set up a feature branch for collaborative development Policy decisions on release management can be deferred for now, since they will be largely in the hands of the Python 3.3 Release Manager. Cheers, Nick. -- Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia From barry at python.org Fri Feb 4 16:58:14 2011 From: barry at python.org (Barry Warsaw) Date: Fri, 4 Feb 2011 10:58:14 -0500 Subject: [python-committers] Create a Mercurial repository with a branch per issue In-Reply-To: <4D4C1CB9.6040203@egenix.com> References: <1296820351.742.27.camel@marge> <4D4BEC34.8080902@jcea.es> <1296821742.1739.3.camel@marge> <4D4BF618.2070100@jcea.es> <4D4C03C9.5070308@jcea.es> <4D4C1CB9.6040203@egenix.com> Message-ID: <20110204105814.02cb05e6@python.org> On Feb 04, 2011, at 04:35 PM, M.-A. Lemburg wrote: >Tarek Ziad? wrote: >> You are building a patch and submit it to reviews (in roundup or in a >> clone or retvield etc). You get feedback and you refine the patch. >> >> I don't think you want to keep that history, e.g. "changing this and >> that in my patch after feedback from MrX about Y" >> >> The main line history is what counts imo, not the history of how your >> patch was built, refactored etc. before it got merged. > >+1 I guess this is just a Mercurial quirk I'll have to get used to. It's not something I ever bother with in Bazaar because, while those intermediate commits are still part of the merged branch's history, it's generally hidden from you when you dump the log or bisect, unless you specifically request to see them. I wholeheartedly agree with the suggestion that we need a best practices guide before the migration is operational, even if it changes over time. Let's get everyone starting on the same page. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From barry at python.org Fri Feb 4 17:03:25 2011 From: barry at python.org (Barry Warsaw) Date: Fri, 4 Feb 2011 11:03:25 -0500 Subject: [python-committers] =?utf-8?q?=5BPSF-Members=5D_Code_Simplicity_?= =?utf-8?q?=C2=BB_Open_Source_Community=2C_Simplified?= In-Reply-To: <4D4B6E28.4010209@jcea.es> References: <4D495CBA.6040706@python.org> <20110202114702.133c59de@python.org> <4D4993C2.9080909@jcea.es> <1296668327.3718.8.camel@localhost.localdomain> <4D49A093.4020909@jcea.es> <1296671319.3718.9.camel@localhost.localdomain> <4D49A4D0.8070908@jcea.es> <1296672429.3718.12.camel@localhost.localdomain> <4D49BC33.3030706@jcea.es> <20110202153001.527be580@python.org> <4D49F8CD.90807@jcea.es> <4D4B6E28.4010209@jcea.es> Message-ID: <20110204110325.4e172d3c@python.org> On Feb 04, 2011, at 04:10 AM, Jesus Cea wrote: >If we up-port, no patch is forgotten. The rule should be: "patches in >n+1 are a SUPERSET of patches in n". With this rule, mercurial takes >care of everything (a patch in n+1 can 'undo' a patch up-ported from n, >if needed, keeping the rule). I'm not totally convinced, but I'm willing to suspend my disbelieve and embrace The Mercurial Way to see how well it works in practice. ;) >> The worse possibility is that fixes may be applied to maintenance >> branches and not to the main line of development, leading to >> regressions after upgrades (since the associated tests wouldn't be >> forward ported either). > >That is not going to happen, because the mercurial merging between >maintenance and development. This is the up-porting side, and merging >should be automatic, you don't need to track anything, it is >automagically done by mercurial. Given that this workflow is a social one, encouraged but not imposed by the technology, how will we respond when things are done The Wrong Way? What are the effects if someone forgets and commits a patch to trunk first? Have we hosed the branches or is it just a PITA to recover? -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From g.brandl at gmx.net Fri Feb 4 17:14:24 2011 From: g.brandl at gmx.net (Georg Brandl) Date: Fri, 04 Feb 2011 17:14:24 +0100 Subject: [python-committers] =?iso-8859-1?q?=5BPSF-Members=5D_Code_Simplic?= =?iso-8859-1?q?ity_=BB_Open_Source_Community=2C_Simplified?= In-Reply-To: <20110204110325.4e172d3c@python.org> References: <4D495CBA.6040706@python.org> <20110202114702.133c59de@python.org> <4D4993C2.9080909@jcea.es> <1296668327.3718.8.camel@localhost.localdomain> <4D49A093.4020909@jcea.es> <1296671319.3718.9.camel@localhost.localdomain> <4D49A4D0.8070908@jcea.es> <1296672429.3718.12.camel@localhost.localdomain> <4D49BC33.3030706@jcea.es> <20110202153001.527be580@python.org> <4D49F8CD.90807@jcea.es> <4D4B6E28.4010209@jcea.es> <20110204110325.4e172d3c@python.org> Message-ID: Am 04.02.2011 17:03, schrieb Barry Warsaw: >>> The worse possibility is that fixes may be applied to maintenance >>> branches and not to the main line of development, leading to >>> regressions after upgrades (since the associated tests wouldn't be >>> forward ported either). >> >>That is not going to happen, because the mercurial merging between >>maintenance and development. This is the up-porting side, and merging >>should be automatic, you don't need to track anything, it is >>automagically done by mercurial. > > Given that this workflow is a social one, encouraged but not imposed by the > technology, how will we respond when things are done The Wrong Way? What are > the effects if someone forgets and commits a patch to trunk first? Have we > hosed the branches or is it just a PITA to recover? The patch will be committed to maintenance separately and thus occur twice in the changeset history. At the next merging of maintenance into trunk, Mercurial will notice that both changesets have in the same result and it's fine. If the maintenance commit is different to the trunk commit, there will be a merge conflict to be resolved by ignoring the changes from maintenance. Georg From barry at python.org Fri Feb 4 17:21:04 2011 From: barry at python.org (Barry Warsaw) Date: Fri, 4 Feb 2011 11:21:04 -0500 Subject: [python-committers] =?utf-8?q?=5BPSF-Members=5D_Code_Simplicity_?= =?utf-8?q?=C2=BB_Open_Source_Community=2C_Simplified?= In-Reply-To: <1296819321.742.13.camel@marge> References: <4D495CBA.6040706@python.org> <20110202114702.133c59de@python.org> <1296819321.742.13.camel@marge> Message-ID: <20110204112104.18638134@python.org> On Feb 04, 2011, at 12:35 PM, Victor Stinner wrote: >I am already using a DVCS (git-svn) to work on Python, especially for my >work on Unicode. It is just impossible to work on an huge change on >trunk, it changes too fast. A SVN branch should be created or a DVCS >tool should be used. I prefer DVCS over SVN: it's faster, it's easier to >do small commits, merge/remove commits, etc. I did all of my PEP work for 3.2 in a Bazaar mirror of the py3k svn branch. I made zillions of small commits as I was working things out, and it was very easy for me to generate diffs for attaching to the bug tracker. It was also very easy for me to track changes in the trunk. Of course, conflicts happen occasionally, but that's unavoidable and IME were easily resolved. For the actual commits to trunk though, I generated a patch and applied it to the official svn branch. I probably could have used the bzr-svn plugin to do the commit directly, but for vague reasons I didn't. >But my last problem is that I don't know how to publish my DVCS >repository. It would be possible to host it at home, but I am to lazy to >setup my server for that. The problem is also that the repository is >huge (254 MB): publish it to Internet would be slow (I upload at 80 >KB/sec) if I have to publish all files (and the history) the first time. >It would be faster if I can fork an existing repository on a server >(download is always faster than upload). > >I suppose that bitbucket will have a miror of Python (because they >already proposed to host the official repository), and so it will be >trivial to fork Python repository with just a bitbucket account. That >will be great, because it will easier to share a branch, without having >to be a Python core developer. We should most definitely host branches of works-in-progress for core committers, just as we do for the official branches. The fact that there are free code hosting services available should make it easy for anybody to publish their branches, anywhere they want. >We might also host forks on our server, but it implies to have to >manager user accounts (with permissions), so do the same job than >Bitbucket and other hosting websites. We already have to manage user accounts for core committers, so for them, there should be little additional work. In fact, two years ago, we did set up personal code hosting on python.org servers for both the Mercurial and Bazaar experiments. It's definitely more work to manage user accounts for non-core committers, so I'm not suggesting we do that from the start, but we should be open to that option if we have the volunteers to maintain that. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From dirkjan at ochtman.nl Fri Feb 4 17:25:15 2011 From: dirkjan at ochtman.nl (Dirkjan Ochtman) Date: Fri, 4 Feb 2011 17:25:15 +0100 Subject: [python-committers] =?utf-8?q?=5BPSF-Members=5D_Code_Simplicity_?= =?utf-8?q?=C2=BB_Open_Source_Community=2C_Simplified?= In-Reply-To: References: <4D495CBA.6040706@python.org> <20110202114702.133c59de@python.org> <4D4993C2.9080909@jcea.es> <1296668327.3718.8.camel@localhost.localdomain> <4D49A093.4020909@jcea.es> <1296671319.3718.9.camel@localhost.localdomain> <4D49A4D0.8070908@jcea.es> <1296672429.3718.12.camel@localhost.localdomain> <4D49BC33.3030706@jcea.es> <20110202153001.527be580@python.org> <4D49F8CD.90807@jcea.es> <4D4B6E28.4010209@jcea.es> <1296822354.3774.3.camel@localhost.localdomain> <20110204143019.5B3DB241BF5@kimball.webabinitio.net> Message-ID: On Fri, Feb 4, 2011 at 16:49, Nick Coghlan wrote: > On the other hand, if *any* forward port naturally picks up all the > missed forward ports, then the Mercurial perspective starts to make > more sense (especially if the merge is able to exploit the DAG in > order to make fewer mistakes). That's exactly the idea of the Mercurial way. You type hg merge and it will merge everything from the other branch that hasn't been merged yet (where both "blocking", in svnmerge terminology, and merging count as having been merged). Cheers, Dirkjan From solipsis at pitrou.net Fri Feb 4 17:31:34 2011 From: solipsis at pitrou.net (Antoine Pitrou) Date: Fri, 04 Feb 2011 17:31:34 +0100 Subject: [python-committers] =?iso-8859-1?q?=5BPSF-Members=5D_Code_Simplic?= =?iso-8859-1?q?ity_=BB_Open_Source_Community=2C_Simplified?= In-Reply-To: References: <4D495CBA.6040706@python.org> <20110202114702.133c59de@python.org> <4D4993C2.9080909@jcea.es> <1296668327.3718.8.camel@localhost.localdomain> <4D49A093.4020909@jcea.es> <1296671319.3718.9.camel@localhost.localdomain> <4D49A4D0.8070908@jcea.es> <1296672429.3718.12.camel@localhost.localdomain> <4D49BC33.3030706@jcea.es> <20110202153001.527be580@python.org> <4D49F8CD.90807@jcea.es> <4D4B6E28.4010209@jcea.es> <1296822354.3774.3.camel@localhost.localdomain> <20110204143019.5B3DB241BF5@kimball.webabinitio.net> Message-ID: <1296837094.3774.10.camel@localhost.localdomain> Le vendredi 04 f?vrier 2011 ? 17:25 +0100, Dirkjan Ochtman a ?crit : > On Fri, Feb 4, 2011 at 16:49, Nick Coghlan wrote: > > On the other hand, if *any* forward port naturally picks up all the > > missed forward ports, then the Mercurial perspective starts to make > > more sense (especially if the merge is able to exploit the DAG in > > order to make fewer mistakes). > > That's exactly the idea of the Mercurial way. You type hg merge > and it will merge everything from the other branch that > hasn't been merged yet (where both "blocking", in svnmerge > terminology, and merging count as having been merged). How do you "block"? From barry at python.org Fri Feb 4 17:36:10 2011 From: barry at python.org (Barry Warsaw) Date: Fri, 4 Feb 2011 11:36:10 -0500 Subject: [python-committers] =?utf-8?q?=5BPSF-Members=5D_Code_Simplicity_?= =?utf-8?q?=C2=BB_Open_Source_Community=2C_Simplified?= In-Reply-To: References: <4D495CBA.6040706@python.org> <20110202114702.133c59de@python.org> <4D4993C2.9080909@jcea.es> <1296668327.3718.8.camel@localhost.localdomain> <4D49A093.4020909@jcea.es> <1296671319.3718.9.camel@localhost.localdomain> <4D49A4D0.8070908@jcea.es> <1296672429.3718.12.camel@localhost.localdomain> <4D49BC33.3030706@jcea.es> <20110202153001.527be580@python.org> <4D49F8CD.90807@jcea.es> <4D4B6E28.4010209@jcea.es> <1296822354.3774.3.camel@localhost.localdomain> <20110204143019.5B3DB241BF5@kimball.webabinitio.net> Message-ID: <20110204113610.7afd1a90@python.org> On Feb 04, 2011, at 05:25 PM, Dirkjan Ochtman wrote: >On Fri, Feb 4, 2011 at 16:49, Nick Coghlan wrote: >> On the other hand, if *any* forward port naturally picks up all the >> missed forward ports, then the Mercurial perspective starts to make >> more sense (especially if the merge is able to exploit the DAG in >> order to make fewer mistakes). > >That's exactly the idea of the Mercurial way. You type hg merge > and it will merge everything from the other branch that >hasn't been merged yet (where both "blocking", in svnmerge >terminology, and merging count as having been merged). Doesn't that mean that the person doing the forward port will potentially have to review a lot more code than the fix they specifically want to make? IOW, if I apply a patch to 3.1 and forget to forward port it to 3.2 and the trunk, then you also apply a patch to 3.1 and *do* the forward port, you could end up with conflicts resulting from my merge. That change might or might not make sense to you, but in a way, you shouldn't even have to worry about it because it interrupts the work you're doing on your patch. What if my fix for 3.1 isn't applicable to 3.2 or the trunk? Wouldn't it be better for you to have to only deal with your change, and then admonish me for not completing my patch by making sure it is correctly committed to all branches in which it applies? -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From dirkjan at ochtman.nl Fri Feb 4 17:37:09 2011 From: dirkjan at ochtman.nl (Dirkjan Ochtman) Date: Fri, 4 Feb 2011 17:37:09 +0100 Subject: [python-committers] =?utf-8?q?=5BPSF-Members=5D_Code_Simplicity_?= =?utf-8?q?=C2=BB_Open_Source_Community=2C_Simplified?= In-Reply-To: <1296837094.3774.10.camel@localhost.localdomain> References: <4D495CBA.6040706@python.org> <20110202114702.133c59de@python.org> <4D4993C2.9080909@jcea.es> <1296668327.3718.8.camel@localhost.localdomain> <4D49A093.4020909@jcea.es> <1296671319.3718.9.camel@localhost.localdomain> <4D49A4D0.8070908@jcea.es> <1296672429.3718.12.camel@localhost.localdomain> <4D49BC33.3030706@jcea.es> <20110202153001.527be580@python.org> <4D49F8CD.90807@jcea.es> <4D4B6E28.4010209@jcea.es> <1296822354.3774.3.camel@localhost.localdomain> <20110204143019.5B3DB241BF5@kimball.webabinitio.net> <1296837094.3774.10.camel@localhost.localdomain> Message-ID: On Fri, Feb 4, 2011 at 17:31, Antoine Pitrou wrote: >> That's exactly the idea of the Mercurial way. You type hg merge >> and it will merge everything from the other branch that >> hasn't been merged yet (where both "blocking", in svnmerge >> terminology, and merging count as having been merged). > > How do you "block"? By reverting changes during the merge (after hg merge, before hg commit). Cheers, Dirkjan From dirkjan at ochtman.nl Fri Feb 4 17:46:29 2011 From: dirkjan at ochtman.nl (Dirkjan Ochtman) Date: Fri, 4 Feb 2011 17:46:29 +0100 Subject: [python-committers] =?utf-8?q?=5BPSF-Members=5D_Code_Simplicity_?= =?utf-8?q?=C2=BB_Open_Source_Community=2C_Simplified?= In-Reply-To: <20110204113610.7afd1a90@python.org> References: <4D495CBA.6040706@python.org> <20110202114702.133c59de@python.org> <4D4993C2.9080909@jcea.es> <1296668327.3718.8.camel@localhost.localdomain> <4D49A093.4020909@jcea.es> <1296671319.3718.9.camel@localhost.localdomain> <4D49A4D0.8070908@jcea.es> <1296672429.3718.12.camel@localhost.localdomain> <4D49BC33.3030706@jcea.es> <20110202153001.527be580@python.org> <4D49F8CD.90807@jcea.es> <4D4B6E28.4010209@jcea.es> <1296822354.3774.3.camel@localhost.localdomain> <20110204143019.5B3DB241BF5@kimball.webabinitio.net> <20110204113610.7afd1a90@python.org> Message-ID: On Fri, Feb 4, 2011 at 17:36, Barry Warsaw wrote: > Doesn't that mean that the person doing the forward port will potentially have > to review a lot more code than the fix they specifically want to make? Potentially, yes. I would imagine in many cases (let's not count 2.x -> 3.x for now) the merge wouldn't be that hard, and most fixes should be easy to recognize as applicable. But if not, this should incentivize people to forward-port their own changes, which is a good thing, IMO. Cheers, Dirkjan From barry at python.org Fri Feb 4 17:51:15 2011 From: barry at python.org (Barry Warsaw) Date: Fri, 4 Feb 2011 11:51:15 -0500 Subject: [python-committers] =?utf-8?q?=5BPSF-Members=5D_Code_Simplicity_?= =?utf-8?q?=C2=BB_Open_Source_Community=2C_Simplified?= In-Reply-To: References: <4D495CBA.6040706@python.org> <20110202114702.133c59de@python.org> <4D4993C2.9080909@jcea.es> <1296668327.3718.8.camel@localhost.localdomain> <4D49A093.4020909@jcea.es> <1296671319.3718.9.camel@localhost.localdomain> <4D49A4D0.8070908@jcea.es> <1296672429.3718.12.camel@localhost.localdomain> <4D49BC33.3030706@jcea.es> <20110202153001.527be580@python.org> <4D49F8CD.90807@jcea.es> <4D4B6E28.4010209@jcea.es> <1296822354.3774.3.camel@localhost.localdomain> <20110204143019.5B3DB241BF5@kimball.webabinitio.net> <20110204113610.7afd1a90@python.org> Message-ID: <20110204115115.7247130a@python.org> On Feb 04, 2011, at 05:46 PM, Dirkjan Ochtman wrote: >But if not, this should incentivize people to forward-port their own >changes, which is a good thing, IMO. Sure. I guess my question is, what do *you* do in that case? Are you blocked because I didn't do my job properly? Can you tell your merge to ignore my change so you can keep making progress, complete your patch, and send me a nastygram to finish my work? :) -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From dirkjan at ochtman.nl Fri Feb 4 18:03:14 2011 From: dirkjan at ochtman.nl (Dirkjan Ochtman) Date: Fri, 4 Feb 2011 18:03:14 +0100 Subject: [python-committers] =?utf-8?q?=5BPSF-Members=5D_Code_Simplicity_?= =?utf-8?q?=C2=BB_Open_Source_Community=2C_Simplified?= In-Reply-To: <20110204115115.7247130a@python.org> References: <4D495CBA.6040706@python.org> <20110202114702.133c59de@python.org> <4D4993C2.9080909@jcea.es> <1296668327.3718.8.camel@localhost.localdomain> <4D49A093.4020909@jcea.es> <1296671319.3718.9.camel@localhost.localdomain> <4D49A4D0.8070908@jcea.es> <1296672429.3718.12.camel@localhost.localdomain> <4D49BC33.3030706@jcea.es> <20110202153001.527be580@python.org> <4D49F8CD.90807@jcea.es> <4D4B6E28.4010209@jcea.es> <1296822354.3774.3.camel@localhost.localdomain> <20110204143019.5B3DB241BF5@kimball.webabinitio.net> <20110204113610.7afd1a90@python.org> <20110204115115.7247130a@python.org> Message-ID: On Fri, Feb 4, 2011 at 17:51, Barry Warsaw wrote: > Sure. ?I guess my question is, what do *you* do in that case? ?Are you blocked > because I didn't do my job properly? ?Can you tell your merge to ignore my > change so you can keep making progress, complete your patch, and send me a > nastygram to finish my work? :) You could: - merge the other's stuff and tell them to check if you merged it correctly - don't merge the other's stuff and tell them to patch it in again - backout the other's stuff, proceed as planned (optionally re-commit other's stuff) In general: sure, there are all kinds of ways to mangle history and make it work. Cheers, Dirkjan From g.brandl at gmx.net Fri Feb 4 18:54:21 2011 From: g.brandl at gmx.net (Georg Brandl) Date: Fri, 04 Feb 2011 18:54:21 +0100 Subject: [python-committers] =?utf-8?q?=5BPSF-Members=5D_Code_Simplicity_?= =?utf-8?q?=C2=BB_Open_Source_Community=2C_Simplified?= In-Reply-To: References: <4D495CBA.6040706@python.org> <20110202114702.133c59de@python.org> <4D4993C2.9080909@jcea.es> <1296668327.3718.8.camel@localhost.localdomain> <4D49A093.4020909@jcea.es> <1296671319.3718.9.camel@localhost.localdomain> <4D49A4D0.8070908@jcea.es> <1296672429.3718.12.camel@localhost.localdomain> <4D49BC33.3030706@jcea.es> <20110202153001.527be580@python.org> <4D49F8CD.90807@jcea.es> <4D4B6E28.4010209@jcea.es> <1296822354.3774.3.camel@localhost.localdomain> <20110204143019.5B3DB241BF5@kimball.webabinitio.net> <20110204113610.7afd1a90@python.org> <20110204115115.7247130a@python.org> Message-ID: Am 04.02.2011 18:03, schrieb Dirkjan Ochtman: > On Fri, Feb 4, 2011 at 17:51, Barry Warsaw wrote: >> Sure. I guess my question is, what do *you* do in that case? Are you blocked >> because I didn't do my job properly? Can you tell your merge to ignore my >> change so you can keep making progress, complete your patch, and send me a >> nastygram to finish my work? :) > > You could: > > - merge the other's stuff and tell them to check if you merged it correctly > - don't merge the other's stuff and tell them to patch it in again > - backout the other's stuff, proceed as planned (optionally re-commit > other's stuff) > > In general: sure, there are all kinds of ways to mangle history and > make it work. I think the easiest way would be to - base your changes onto a revision that doesn't contain the other's unmerged change, and merge that one. Georg From jcea at jcea.es Fri Feb 4 19:03:37 2011 From: jcea at jcea.es (Jesus Cea) Date: Fri, 04 Feb 2011 19:03:37 +0100 Subject: [python-committers] =?iso-8859-15?q?=5BPSF-Members=5D_Code_Simpli?= =?iso-8859-15?q?city_=BB_Open_Source_Community=2C_Simplified?= In-Reply-To: References: <4D495CBA.6040706@python.org> <20110202114702.133c59de@python.org> <4D4993C2.9080909@jcea.es> <1296668327.3718.8.camel@localhost.localdomain> <4D49A093.4020909@jcea.es> <1296671319.3718.9.camel@localhost.localdomain> <4D49A4D0.8070908@jcea.es> <1296672429.3718.12.camel@localhost.localdomain> <4D49BC33.3030706@jcea.es> <20110202153001.527be580@python.org> <4D49F8CD.90807@jcea.es> <4D4B6E28.4010209@jcea.es> <1296822354.3774.3.camel@localhost.localdomain> <20110204143019.5B3DB241BF5@kimball.webabinitio.net> Message-ID: <4D4C3F79.90004@jcea.es> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/02/11 16:49, Nick Coghlan wrote: > On the other hand, if *any* forward port naturally picks up all the > missed forward ports, then the Mercurial perspective starts to make > more sense (especially if the merge is able to exploit the DAG in > order to make fewer mistakes). A mercurial merge "brings" "automatically" (if can be done) any patch in a side, to the other side. Basically "joins" the two sides making a single one. clone 1: A->B->C->D Clone 2: A->E->F->G->H When you merge you have: A->B->C->D--------->I \ / \->E->F->G->H-/ Code in "I" contains all "B", "C", "D", "E", "F", "G" and "H". This merging is "automatic" (if there are no conflicts!). That is the magic in Mercurial. The merge machinery. It is a huge improvement over subversion, even in 1.6.*. - -- 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/ iQCVAwUBTUw/eZlgi5GaxT1NAQJjdwP/dF6H2K9sdOUrXJ9jwJxwwgZzrGDQfM0p OG1sKTUCnn7WKC0II2Ep56BdVMC7HvF5PT9fQDOMKwyDz2WN02YgTIxvrHwh4wHz 90zXvDB7VslH5k1shXm7v++mqgutWDMOUHRJ73ZjKuS6rSnf69m4yCN7PK0stGcX 1uHaPiMJI+8= =p9Zg -----END PGP SIGNATURE----- From jcea at jcea.es Fri Feb 4 19:18:24 2011 From: jcea at jcea.es (Jesus Cea) Date: Fri, 04 Feb 2011 19:18:24 +0100 Subject: [python-committers] Create a Mercurial repository with a branch per issue In-Reply-To: <20110204105814.02cb05e6@python.org> References: <1296820351.742.27.camel@marge> <4D4BEC34.8080902@jcea.es> <1296821742.1739.3.camel@marge> <4D4BF618.2070100@jcea.es> <4D4C03C9.5070308@jcea.es> <4D4C1CB9.6040203@egenix.com> <20110204105814.02cb05e6@python.org> Message-ID: <4D4C42F0.9060106@jcea.es> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/02/11 16:58, Barry Warsaw wrote: > I guess this is just a Mercurial quirk I'll have to get used to. It's not > something I ever bother with in Bazaar because, while those intermediate > commits are still part of the merged branch's history, it's generally hidden > from you when you dump the log or bisect, unless you specifically request to > see them. """ $ hg help log [...] - --follow-first only follow the first parent of merge changesets [...] - -m --only-merges show only merges [...] - -M --no-merges do not show merges [...] """ Would be interesting that "bisect" would be "improved" to follow only the first parent in a merge. - -- 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/ iQCVAwUBTUxC8Jlgi5GaxT1NAQJ0tQP/dHk0izxHp2NLFMiTao5+bDdE5vADcj4+ aSyAZGCiw6ozLu/KZFTFKujcsnzshXwaHWacUk3RMVzUNctRVHSCnRwMnwII+SUL 8a4uMqY31Xc4nqzIycFjYeU7gSQGhbOq0z0FFU2LW1BChVQ8YUwQbUpeSN7pgopS 1enrdo6U9ls= =HilB -----END PGP SIGNATURE----- From jcea at jcea.es Fri Feb 4 19:28:20 2011 From: jcea at jcea.es (Jesus Cea) Date: Fri, 04 Feb 2011 19:28:20 +0100 Subject: [python-committers] =?iso-8859-15?q?=5BPSF-Members=5D_Code_Simpli?= =?iso-8859-15?q?city_=BB_Open_Source_Community=2C_Simplified?= In-Reply-To: <20110204110325.4e172d3c@python.org> References: <4D495CBA.6040706@python.org> <20110202114702.133c59de@python.org> <4D4993C2.9080909@jcea.es> <1296668327.3718.8.camel@localhost.localdomain> <4D49A093.4020909@jcea.es> <1296671319.3718.9.camel@localhost.localdomain> <4D49A4D0.8070908@jcea.es> <1296672429.3718.12.camel@localhost.localdomain> <4D49BC33.3030706@jcea.es> <20110202153001.527be580@python.org> <4D49F8CD.90807@jcea.es> <4D4B6E28.4010209@jcea.es> <20110204110325.4e172d3c@python.org> Message-ID: <4D4C4544.1050601@jcea.es> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/02/11 17:03, Barry Warsaw wrote: > Given that this workflow is a social one, encouraged but not imposed by the > technology, how will we respond when things are done The Wrong Way? What are > the effects if someone forgets and commits a patch to trunk first? Have we > hosed the branches or is it just a PITA to recover? The obvious approach would be to use "transplant" to copy the patch to the "old" clone. If the patch in both places is the same, mercurial recognize the fact. If they are not, you have a false conflict, to be resolved in the merge (usually you do this just now, that you have the details fresh in mind, and if you don't do, somebody has to do it). Other option is to export the patch from the "new" clone, backout the patch ("hg backout" command), apply the patch to the "old" clone and then do a regular merge. As said, this is a social problem. For instance, if I write a patch to "new" and do not backport, somebody else can do it "eventually". This is practical, but you can "forget" or decide you don't want to spend your time maintaining, let's say, 2.7.*. But using "up-porting", when somebody does a merge from "old" to "new", the operation brings all patches from "old". If the patches doesn't apply cleanly (mercurial merge machinery is clever, but not everything can be done automatically), the guy doing a merge is going to curse badly. Ideally, every changeset committed to "old" should be "merged" inmediatelly to "new", by the patch maker. I don't consider an issue to be "closed" until this is done. Not sure if this should be a real rule, but if "old" and "new" reside in the same repository (for instance, named branches), you can check this in the push "hook" living in the server. That is, the hook check that the changesets you are pushing don't create a new head in "old" (your patch create a head, but your merge "joins" heads in both "old" and "new". When you push, you push both changesets at the same time, and the repository is verified and updated atomically). - -- 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/ iQCVAwUBTUxFRJlgi5GaxT1NAQJmpAP/bmdgoK4J4O/hS+DNrC59sVxOU0Y5gH4I gW7SnU/FDejszMeDJ8fi6/3/v4jcV+Mfy9MOSr4lCmfnmXXXUyHoMBL5UEmDvuGR LNN3QXEKZeNo5op4UQWa1rRp9qjYL95R/dBiVPgGY6Ia+V406fjdgYFXVn331KhY 0qpf5/teZ4c= =FYnu -----END PGP SIGNATURE----- From jcea at jcea.es Fri Feb 4 19:41:00 2011 From: jcea at jcea.es (Jesus Cea) Date: Fri, 04 Feb 2011 19:41:00 +0100 Subject: [python-committers] =?iso-8859-15?q?=5BPSF-Members=5D_Code_Simpli?= =?iso-8859-15?q?city_=BB_Open_Source_Community=2C_Simplified?= In-Reply-To: <1296837094.3774.10.camel@localhost.localdomain> References: <4D495CBA.6040706@python.org> <20110202114702.133c59de@python.org> <4D4993C2.9080909@jcea.es> <1296668327.3718.8.camel@localhost.localdomain> <4D49A093.4020909@jcea.es> <1296671319.3718.9.camel@localhost.localdomain> <4D49A4D0.8070908@jcea.es> <1296672429.3718.12.camel@localhost.localdomain> <4D49BC33.3030706@jcea.es> <20110202153001.527be580@python.org> <4D49F8CD.90807@jcea.es> <4D4B6E28.4010209@jcea.es> <1296822354.3774.3.camel@localhost.localdomain> <20110204143019.5B3DB241BF5@kimball.webabinitio.net> <1296837094.3774.10.camel@localhost.localdomain> Message-ID: <4D4C483C.1060101@jcea.es> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/02/11 17:31, Antoine Pitrou wrote: > How do you "block"? What patches in "3.2" you don't want in "3.3"?. Remember the rule: "Patches in n+1 are a SUPERSET of patches in n". But a patch in "n+1" can undo a patch in "n", keeping this rule true always. The usual approach is to do a merge just before the patch you don't want, and then a "null merge" just after the patch you don't want. "null merge" = a merge metadata update without actually bringing any new code. I can't think any reason you want this, beside avoiding the "change 3.2 to 3.2.1 strings" to propagate to trunk. In this particular situation, the merge would conflict (because "3.2->3.2.1" conflicts with "3.3", no "3.2" anywhere in trunk). Solving this conflict is trivial (just drop that change), and now you can retry merging again, this time successfully. Ideally, when you push to the repository, you push your patches *AND* the merges, all in an atomic operation. So you don't move the merge burden to somebody else. I just wrote about this in a just sent email. - -- 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/ iQCVAwUBTUxIPJlgi5GaxT1NAQK2IQP/d8+ILx4EukYf65m6OYn749TJ5jvejKgI 4m+O2CAnJIORiOo9jYhp12GUanCeziBDVcdVNx9sFRAHB2QNowVhxbJv+B50/WSF NXIlGxJaQcbCC4TlniJtnWezPzCr/cfNmxlUFv10qLErl2gEfMUCQMLC0/Zh9BDg f+8gpoaiBt0= =FVbK -----END PGP SIGNATURE----- From jcea at jcea.es Fri Feb 4 19:47:32 2011 From: jcea at jcea.es (Jesus Cea) Date: Fri, 04 Feb 2011 19:47:32 +0100 Subject: [python-committers] =?iso-8859-15?q?=5BPSF-Members=5D_Code_Simpli?= =?iso-8859-15?q?city_=BB_Open_Source_Community=2C_Simplified?= In-Reply-To: <20110204115115.7247130a@python.org> References: <4D495CBA.6040706@python.org> <20110202114702.133c59de@python.org> <4D4993C2.9080909@jcea.es> <1296668327.3718.8.camel@localhost.localdomain> <4D49A093.4020909@jcea.es> <1296671319.3718.9.camel@localhost.localdomain> <4D49A4D0.8070908@jcea.es> <1296672429.3718.12.camel@localhost.localdomain> <4D49BC33.3030706@jcea.es> <20110202153001.527be580@python.org> <4D49F8CD.90807@jcea.es> <4D4B6E28.4010209@jcea.es> <1296822354.3774.3.camel@localhost.localdomain> <20110204143019.5B3DB241BF5@kimball.webabinitio.net> <20110204113610.7afd1a90@python.org> <20110204115115.7247130a@python.org> Message-ID: <4D4C49C4.2080403@jcea.es> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/02/11 17:51, Barry Warsaw wrote: > Sure. I guess my question is, what do *you* do in that case? Are > you blocked because I didn't do my job properly? Can you tell your > merge to ignore my change so you can keep making progress, complete > your patch, and send me a nastygram to finish my work? :) You can, but is not trivial neither automatic. There are quite a few strategies. For instance, I can move my patch BEFORE your patch (v?a rebase), creating a new head, and merging my head with trunk. My head is solved. Yours is still hanging around. Or you can force this via a push "hook": no heads left behind! :-) I just wrote an email about this. - -- 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/ iQCVAwUBTUxJxJlgi5GaxT1NAQJejwQAmrR9PuJmvL/FcKHYirsKk5A0gvoebG8v Sd7baUi3dfcWR4HEsJa5SLc1knY+f/wlFyDzd0fYx102+QMgYUiipp8n9r3+yXfN PSR1tREix93Zbb2dlfkSQe6L0+pfz6hXZRNHMBCgN9EFpIspcD05/yZVISwsBHyG 80EKgV1+FGg= =2D3a -----END PGP SIGNATURE----- From tjreedy at udel.edu Fri Feb 4 20:55:06 2011 From: tjreedy at udel.edu (Terry Reedy) Date: Fri, 04 Feb 2011 14:55:06 -0500 Subject: [python-committers] =?iso-8859-1?q?=5BPSF-Members=5D_Code_Simplic?= =?iso-8859-1?q?ity_=BB_Open_Source_Community=2C_Simplified?= In-Reply-To: <4D4C483C.1060101@jcea.es> References: <4D495CBA.6040706@python.org> <20110202114702.133c59de@python.org> <4D4993C2.9080909@jcea.es> <1296668327.3718.8.camel@localhost.localdomain> <4D49A093.4020909@jcea.es> <1296671319.3718.9.camel@localhost.localdomain> <4D49A4D0.8070908@jcea.es> <1296672429.3718.12.camel@localhost.localdomain> <4D49BC33.3030706@jcea.es> <20110202153001.527be580@python.org> <4D49F8CD.90807@jcea.es> <4D4B6E28.4010209@jcea.es> <1296822354.3774.3.camel@localhost.localdomain> <20110204143019.5B3DB241BF5@kimball.webabinitio.net> <1296837094.3774.10.camel@localhost.localdomain> <4D4C483C.1060101@jcea.es> Message-ID: <4D4C599A.9090205@udel.edu> On 2/4/2011 1:41 PM, Jesus Cea 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. > a patch in "n+1" can undo a patch in "n", keeping this rule true always. > The usual approach is to do a merge just before the patch you don't > want, and then a "null merge" just after the patch you don't want. "null > merge" = a merge metadata update without actually bringing any new code. Seems like a lot of work to satisfy an artificial rule. At one time, things were simple. There was an active maintenance branch and trunk. When trunk was released as 2.k final and a new, 2nd maintenance branch created, the older maintenance branch was released as 2.(k-1).m rc1 and (hopefully) a week later, 2.(k-1).m final and retired, thus restoring the number of maintenance branches to one. Whether bug patches went forwards or backwards between maintenance and trunk did not matter too much. It was later decided to put maintenance branches into security-fix mode for a few years before freezing them, but in practice, this has meant little difference. The problem now is that we have a second, increasingly divergent maintenance branch, and will for several years. Python is literally a two-headed giant (monster?-). So I do not think forcing it into a single-head model will work very well. (Note that from a temporal viewpoint, 2.7 -> 3.1 -> 3.2 is backwards, then forwards.) 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. --- Terry Jan Reedy From jcea at jcea.es Sat Feb 5 00:23:49 2011 From: jcea at jcea.es (Jesus Cea) Date: Sat, 05 Feb 2011 00:23:49 +0100 Subject: [python-committers] =?iso-8859-15?q?=5BPSF-Members=5D_Code_Simpli?= =?iso-8859-15?q?city_=BB_Open_Source_Community=2C_Simplified?= In-Reply-To: <4D4C599A.9090205@udel.edu> References: <4D495CBA.6040706@python.org> <20110202114702.133c59de@python.org> <4D4993C2.9080909@jcea.es> <1296668327.3718.8.camel@localhost.localdomain> <4D49A093.4020909@jcea.es> <1296671319.3718.9.camel@localhost.localdomain> <4D49A4D0.8070908@jcea.es> <1296672429.3718.12.camel@localhost.localdomain> <4D49BC33.3030706@jcea.es> <20110202153001.527be580@python.org> <4D49F8CD.90807@jcea.es> <4D4B6E28.4010209@jcea.es> <1296822354.3774.3.camel@localhost.localdomain> <20110204143019.5B3DB241BF5@kimball.webabinitio.net> <1296837094.3774.10.camel@localhost.localdomain> <4D4C483C.1060101@jcea.es> <4D4C599A.9090205@udel.edu> Message-ID: <4D4C8A85.9090405@jcea.es> -----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----- From solipsis at pitrou.net Sat Feb 5 00:36:32 2011 From: solipsis at pitrou.net (Antoine Pitrou) Date: Sat, 05 Feb 2011 00:36:32 +0100 Subject: [python-committers] =?iso-8859-1?q?=5BPSF-Members=5D_Code_Simplic?= =?iso-8859-1?q?ity_=BB_Open_Source_Community=2C_Simplified?= In-Reply-To: <4D4C8A85.9090405@jcea.es> References: <4D495CBA.6040706@python.org> <20110202114702.133c59de@python.org> <4D4993C2.9080909@jcea.es> <1296668327.3718.8.camel@localhost.localdomain> <4D49A093.4020909@jcea.es> <1296671319.3718.9.camel@localhost.localdomain> <4D49A4D0.8070908@jcea.es> <1296672429.3718.12.camel@localhost.localdomain> <4D49BC33.3030706@jcea.es> <20110202153001.527be580@python.org> <4D49F8CD.90807@jcea.es> <4D4B6E28.4010209@jcea.es> <1296822354.3774.3.camel@localhost.localdomain> <20110204143019.5B3DB241BF5@kimball.webabinitio.net> <1296837094.3774.10.camel@localhost.localdomain> <4D4C483C.1060101@jcea.es> <4D4C599A.9090205@udel.edu> <4D4C8A85.9090405@jcea.es> Message-ID: <1296862592.3774.17.camel@localhost.localdomain> > 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". 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. Regards Antoine. From steve at holdenweb.com Sat Feb 5 00:54:20 2011 From: steve at holdenweb.com (Steve Holden) Date: Fri, 4 Feb 2011 18:54:20 -0500 Subject: [python-committers] =?iso-8859-1?q?=5BPSF-Members=5D_Code_Simplic?= =?iso-8859-1?q?ity_=BB_Open_Source_Community=2C_Simplified?= In-Reply-To: <1296862592.3774.17.camel@localhost.localdomain> References: <4D495CBA.6040706@python.org> <20110202114702.133c59de@python.org> <4D4993C2.9080909@jcea.es> <1296668327.3718.8.camel@localhost.localdomain> <4D49A093.4020909@jcea.es> <1296671319.3718.9.camel@localhost.localdomain> <4D49A4D0.8070908@jcea.es> <1296672429.3718.12.camel@localhost.localdomain> <4D49BC33.3030706@jcea.es> <20110202153001.527be580@python.org> <4D49F8CD.90807@jcea.es> <4D4B6E28.4010209@jcea.es> <1296822354.3774.3.camel@localhost.localdomain> <20110204143019.5B3DB241BF5@kimball.webabinitio.net> <1296837094.3774.10.camel@localhost.localdomain> <4D4C483C.1060101@jcea.es> <4D4C599A.9090205@udel.edu> <4D4C8A85.9090405@jcea.es> <1296862592.3774.17.camel@localhost.localdomain> Message-ID: <56B4DC67-C306-40D5-A143-FD1D22FB60D4@holdenweb.com> On Feb 4, 2011, at 6:36 PM, 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". > > 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. > When known workflows emerge we can ask Brett to include them int he developer documentation (which I had hoped would include Hg -- hope springs eternal. regards Steve From jcea at jcea.es Sat Feb 5 01:00:30 2011 From: jcea at jcea.es (Jesus Cea) Date: Sat, 05 Feb 2011 01:00:30 +0100 Subject: [python-committers] =?iso-8859-15?q?=5BPSF-Members=5D_Code_Simpli?= =?iso-8859-15?q?city_=BB_Open_Source_Community=2C_Simplified?= In-Reply-To: <1296862592.3774.17.camel@localhost.localdomain> References: <4D495CBA.6040706@python.org> <20110202114702.133c59de@python.org> <4D4993C2.9080909@jcea.es> <1296668327.3718.8.camel@localhost.localdomain> <4D49A093.4020909@jcea.es> <1296671319.3718.9.camel@localhost.localdomain> <4D49A4D0.8070908@jcea.es> <1296672429.3718.12.camel@localhost.localdomain> <4D49BC33.3030706@jcea.es> <20110202153001.527be580@python.org> <4D49F8CD.90807@jcea.es> <4D4B6E28.4010209@jcea.es> <1296822354.3774.3.camel@localhost.localdomain> <20110204143019.5B3DB241BF5@kimball.webabinitio.net> <1296837094.3774.10.camel@localhost.localdomain> <4D4C483C.1060101@jcea.es> <4D4C599A.9090205@udel.edu> <4D4C8A85.9090405@jcea.es> <1296862592.3774.17.camel@localhost.localdomain> Message-ID: <4D4C931E.5030709@jcea.es> -----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 _/_/ _/_/_/ _/_/_/ 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/ iQCVAwUBTUyTHplgi5GaxT1NAQKNlwP/U7F2PrAJ9/+tKiWg3wemKlxiPDlb42dV mpn5vLNVzZfj6p/nLkNroJiPce9CBL5pfGukD1Gqr+DG3IMh++xEXHk8EtZOPvPP Q/UUjXpHXDSnXtjugXL1nq4329oXUSJZSTIrCHRD6At2ykBBV5xRWDJvplU6zFw5 aMVTFAG3xVI= =nmyY -----END PGP SIGNATURE----- From solipsis at pitrou.net Sat Feb 5 01:07:35 2011 From: solipsis at pitrou.net (Antoine Pitrou) Date: Sat, 05 Feb 2011 01:07:35 +0100 Subject: [python-committers] =?iso-8859-1?q?=5BPSF-Members=5D_Code_Simplic?= =?iso-8859-1?q?ity_=BB_Open_Source_Community=2C_Simplified?= In-Reply-To: <4D4C931E.5030709@jcea.es> References: <4D495CBA.6040706@python.org> <20110202114702.133c59de@python.org> <4D4993C2.9080909@jcea.es> <1296668327.3718.8.camel@localhost.localdomain> <4D49A093.4020909@jcea.es> <1296671319.3718.9.camel@localhost.localdomain> <4D49A4D0.8070908@jcea.es> <1296672429.3718.12.camel@localhost.localdomain> <4D49BC33.3030706@jcea.es> <20110202153001.527be580@python.org> <4D49F8CD.90807@jcea.es> <4D4B6E28.4010209@jcea.es> <1296822354.3774.3.camel@localhost.localdomain> <20110204143019.5B3DB241BF5@kimball.webabinitio.net> <1296837094.3774.10.camel@localhost.localdomain> <4D4C483C.1060101@jcea.es> <4D4C599A.9090205@udel.edu> <4D4C8A85.9090405@jcea.es> <1296862592.3774.17.camel@localhost.localdomain> <4D4C931E.5030709@jcea.es> Message-ID: <1296864455.3774.20.camel@localhost.localdomain> Le samedi 05 f?vrier 2011 ? 01:00 +0100, Jesus Cea a ?crit : > > Someone could sit and produce a > > written proposal evaluating the various possibilities, and we can > > iterate from that. > > I do agree. Can you try writing said document? From martin at v.loewis.de Sat Feb 5 02:00:02 2011 From: martin at v.loewis.de (=?ISO-8859-15?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Sat, 05 Feb 2011 02:00:02 +0100 Subject: [python-committers] =?iso-8859-15?q?=5BPSF-Members=5D_Code_Simpli?= =?iso-8859-15?q?city_=BB_Open_Source_Community=2C_Simplified?= In-Reply-To: <20110202181612.11d54e3a@python.org> References: <4D495CBA.6040706@python.org> <20110202114702.133c59de@python.org> <4D4993C2.9080909@jcea.es> <1296668327.3718.8.camel@localhost.localdomain> <4D49A093.4020909@jcea.es> <1296671319.3718.9.camel@localhost.localdomain> <4D49A4D0.8070908@jcea.es> <1296672429.3718.12.camel@localhost.localdomain> <4D49BC33.3030706@jcea.es> <20110202153001.527be580@python.org> <20110202181612.11d54e3a@python.org> Message-ID: <4D4CA112.7000003@v.loewis.de> Am 03.02.2011 00:16, schrieb Barry Warsaw: > On Feb 03, 2011, at 08:54 AM, Nick Coghlan wrote: > >> I suspect this problem with the preferred DVCS workflow is going to >> cut fairly heavily into the number of bug fixes applied to the >> maintenance branches. > > I'd be really surprised if it *has* to be that way. Just how painful is it in > Mercurial to apply to newest branch first and back port? IIUC, you lose tracking if you let patches flow in the opposite direction (i.e. in the way it is currently). With the new workflow, you can do "hg pull release32-maint" any time in the trunk, and it will integrate all pending patches. You don't have to specify any revision number there; it will just pick all missing changes from the maintenance branch and integrate them into the trunk. If you let patches flow in the other direction, I understand you lose all support from hg wrt. history tracking. There may be ways to still do this through Mercurial commands (instead of generating a patch and manually applying it), but the backported patch will be different from the patch in the trunk, since it will have different parent versions (IIUC, the command is called "transplant"). I don't know whether hg keeps track of what patches have been transplanted, but I doubt it. In any case, this discussion reiterates my point that this project (Mercurial migration) really needs a project lead, who then will also pronounce on usage policies. Otherwise, it's doomed to fail. Regards, Martin From martin at v.loewis.de Sat Feb 5 02:07:52 2011 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Sat, 05 Feb 2011 02:07:52 +0100 Subject: [python-committers] =?iso-8859-1?q?=5BPSF-Members=5D_Code_Simplic?= =?iso-8859-1?q?ity_=BB_Open_Source_Community=2C_Simplified?= In-Reply-To: References: <4D495CBA.6040706@python.org> <20110202114702.133c59de@python.org> <4D4993C2.9080909@jcea.es> <1296668327.3718.8.camel@localhost.localdomain> <4D49A093.4020909@jcea.es> <1296671319.3718.9.camel@localhost.localdomain> <4D49A4D0.8070908@jcea.es> <1296672429.3718.12.camel@localhost.localdomain> <4D49BC33.3030706@jcea.es> <20110202153001.527be580@python.org> Message-ID: <4D4CA2E8.3030506@v.loewis.de> > Indeed. Mainline is the only branch where we *know* most patches need > to be applied. It also means that people can contribute while > maintaining only a single checkout, rather than necessarily needing > all active versions. Notice that you'll automatically will have all active versions available, if PEP 385 is implemented. A single clone will have all maintenance branches as named branches inside, so integrating a bug fix should be a sequence like hg update release32-maint patch hg commit hg update default hg merge release32-maint hg commit -m merged hg push Sprinkle test runs into this to your taste. Regards, Martin From jcea at jcea.es Sat Feb 5 02:18:58 2011 From: jcea at jcea.es (Jesus Cea) Date: Sat, 05 Feb 2011 02:18:58 +0100 Subject: [python-committers] =?iso-8859-15?q?=5BPSF-Members=5D_Code_Simpli?= =?iso-8859-15?q?city_=BB_Open_Source_Community=2C_Simplified?= In-Reply-To: <1296864455.3774.20.camel@localhost.localdomain> References: <20110202114702.133c59de@python.org> <4D4993C2.9080909@jcea.es> <1296668327.3718.8.camel@localhost.localdomain> <4D49A093.4020909@jcea.es> <1296671319.3718.9.camel@localhost.localdomain> <4D49A4D0.8070908@jcea.es> <1296672429.3718.12.camel@localhost.localdomain> <4D49BC33.3030706@jcea.es> <20110202153001.527be580@python.org> <4D49F8CD.90807@jcea.es> <4D4B6E28.4010209@jcea.es> <1296822354.3774.3.camel@localhost.localdomain> <20110204143019.5B3DB241BF5@kimball.webabinitio.net> <1296837094.3774.10.camel@localhost.localdomain> <4D4C483C.1060101@jcea.es> <4D4C599A.9090205@udel.edu> <4D4C8A85.9090405@jcea.es> <1296862592.3774.17.camel@localhost.localdomain> <4D4C931E.5030709@jcea.es> <1296864455.3774.20.camel@localhost.localdomain> Message-ID: <4D4CA582.2030202@jcea.es> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/02/11 01:07, Antoine Pitrou wrote: > > Le samedi 05 f?vrier 2011 ? 01:00 +0100, Jesus Cea a ?crit : >>> Someone could sit and produce a >>> written proposal evaluating the various possibilities, and we can >>> iterate from that. >> >> I do agree. > > Can you try writing said document? I could write down what I already explained this last days. But I have the feeling that it is a losing position. Anyway, anybody has an alternative that doesn't fight against the strenghts of Mercurial?. I would like to read the opinion of the people actually doing the HG migration work. - -- 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/ iQCVAwUBTUylgplgi5GaxT1NAQIutAP/S2XtCWVeaaHxRjI0rWF607idcm5Jq4GG yGBlJ14wrC96ELgAodrbAYEzSmFxlfuYP5hmngBSVR0JfUvxXRVPSll7k6QJ8RC8 2STyu9+bser2n+/JX7wNZJby99Gs1P9Q6Pt+xAJn3kwBPPhYQ2Oz14R8+L39Hl+x 1bxRwSEis8E= =LqsQ -----END PGP SIGNATURE----- From martin at v.loewis.de Sat Feb 5 02:19:20 2011 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Sat, 05 Feb 2011 02:19:20 +0100 Subject: [python-committers] =?iso-8859-1?q?=5BPSF-Members=5D_Code_Simplic?= =?iso-8859-1?q?ity_=BB_Open_Source_Community=2C_Simplified?= In-Reply-To: References: <4D495CBA.6040706@python.org> <20110202114702.133c59de@python.org> <4D4993C2.9080909@jcea.es> <1296668327.3718.8.camel@localhost.localdomain> <4D49A093.4020909@jcea.es> <1296671319.3718.9.camel@localhost.localdomain> <4D49A4D0.8070908@jcea.es> <1296672429.3718.12.camel@localhost.localdomain> <4D49BC33.3030706@jcea.es> <20110202153001.527be580@python.org> <4D49F8CD.90807@jcea.es> <1296735633.3705.3.camel@localhost.localdomain> <4D4B6FE2.8000808@jcea.es> Message-ID: <4D4CA598.7080703@v.loewis.de> Am 04.02.2011 10:54, schrieb Nick Coghlan: > On Fri, Feb 4, 2011 at 1:17 PM, Jesus Cea wrote: >> "Up-porting" CAN'T be forgotten because it is done "automagically" v?a >> mercurial merges. That is the point... > > So developer A checks in a fix on 2.7, then gets sidetracked before > forward porting it. > > When does it make it to 3.2 or the main development branch? > > Does everyone doing a forward merge from the maintenance branches run > the risk of being landed with the task of doing a bulk merge of any > forgotten forward ports before they can forward port the fix they're > actually trying to implement? You picked the wrong example, but: yes. Your example is wrong, because porting between 2.7 and 3.2 won't be using any Mercurial support, and will rely on cherry-picking. It's really the 3.2->trunk merging (and possibly 3.1->3.2->trunk merging) that uses the Mercurial merge tracking. If somebody commits to 3.1, and forgets to forward-merge, the next time somebody commits to 3.1 and then wants to merge will have to merge both changes. In the 3.2->trunk case, this should be easy, since merges happen often, so there won't be much pending changes (and the original committer will still remember, and might be responsive to do the merge himself). In the 3.1->3.2 case, if merging is forgotten, it may take a while until somebody notices, in which case 3.2 will have evolved, so merging becomes more difficult. I guess it would be possible to send a daily report on pending merges (no report if no pending merges), either to python-dev or to the original committer (it might be also possible to determine the original pusher, and send mail to him instead). Regards, Martin From solipsis at pitrou.net Sat Feb 5 02:26:02 2011 From: solipsis at pitrou.net (Antoine Pitrou) Date: Sat, 05 Feb 2011 02:26:02 +0100 Subject: [python-committers] =?iso-8859-1?q?=5BPSF-Members=5D_Code_Simplic?= =?iso-8859-1?q?ity_=BB_Open_Source_Community=2C_Simplified?= In-Reply-To: <4D4CA582.2030202@jcea.es> References: <20110202114702.133c59de@python.org> <4D4993C2.9080909@jcea.es> <1296668327.3718.8.camel@localhost.localdomain> <4D49A093.4020909@jcea.es> <1296671319.3718.9.camel@localhost.localdomain> <4D49A4D0.8070908@jcea.es> <1296672429.3718.12.camel@localhost.localdomain> <4D49BC33.3030706@jcea.es> <20110202153001.527be580@python.org> <4D49F8CD.90807@jcea.es> <4D4B6E28.4010209@jcea.es> <1296822354.3774.3.camel@localhost.localdomain> <20110204143019.5B3DB241BF5@kimball.webabinitio.net> <1296837094.3774.10.camel@localhost.localdomain> <4D4C483C.1060101@jcea.es> <4D4C599A.9090205@udel.edu> <4D4C8A85.9090405@jcea.es> <1296862592.3774.17.camel@localhost.localdomain> <4D4C931E.5030709@jcea.es> <1296864455.3774.20.camel@localhost.localdomain> <4D4CA582.2030202@jcea.es> Message-ID: <1296869162.3774.23.camel@localhost.localdomain> Le samedi 05 f?vrier 2011 ? 02:18 +0100, Jesus Cea a ?crit : > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 05/02/11 01:07, Antoine Pitrou wrote: > > > > Le samedi 05 f?vrier 2011 ? 01:00 +0100, Jesus Cea a ?crit : > >>> Someone could sit and produce a > >>> written proposal evaluating the various possibilities, and we can > >>> iterate from that. > >> > >> I do agree. > > > > Can you try writing said document? > > I could write down what I already explained this last days. But I have > the feeling that it is a losing position. Well, that would certainly be more constructive than sending 15+ messages on python-committers to explain us how we should work ;) > I would like to read the opinion of the people actually doing the HG > migration work. Both Dirkjan and Georg already answered in this thread. Regards Antoine. From martin at v.loewis.de Sat Feb 5 02:26:09 2011 From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=) Date: Sat, 05 Feb 2011 02:26:09 +0100 Subject: [python-committers] =?utf-8?q?=5BPSF-Members=5D_Code_Simplicity_?= =?utf-8?q?=C2=BB_Open_Source_Community=2C_Simplified?= In-Reply-To: <1296822354.3774.3.camel@localhost.localdomain> References: <4D495CBA.6040706@python.org> <20110202114702.133c59de@python.org> <4D4993C2.9080909@jcea.es> <1296668327.3718.8.camel@localhost.localdomain> <4D49A093.4020909@jcea.es> <1296671319.3718.9.camel@localhost.localdomain> <4D49A4D0.8070908@jcea.es> <1296672429.3718.12.camel@localhost.localdomain> <4D49BC33.3030706@jcea.es> <20110202153001.527be580@python.org> <4D49F8CD.90807@jcea.es> <4D4B6E28.4010209@jcea.es> <1296822354.3774.3.camel@localhost.localdomain> Message-ID: <4D4CA731.3090108@v.loewis.de> Am 04.02.2011 13:25, schrieb Antoine Pitrou: > >> The problem now is that patches in the development branch are >> "forgotten" and not backported when appropiate > > Sorry, do you have real examples of this? If you really want to know, I can dig them out. I'm fairly sure I owe 10 or 20 backports to somebody. Some of them may have been backported by somebody else meanwhile. In many cases, the bug tracker will indicate that a backport is still pending, but sometimes, it's really just forgotten "for good". I personally don't see that as a problem. If somebody really wants a certain bug fixed, they can open a new bug report and request a backport. >> If we up-port, no patch is forgotten. The rule should be: "patches in >> n+1 are a SUPERSET of patches in n". With this rule, mercurial takes >> care of everything (a patch in n+1 can 'undo' a patch up-ported from n, >> if needed, keeping the rule). > > That's a theoretical and IMO na?ve point of view. In practice, there are > many changesets that will not "up-port" cleanly and will need manual > work. The work will not be much less than with down-porting. I'm really with Nick here - I don't view *that* as the real problem with the "natural" workflow. Instead, I also predict that some committers just won't bother with backporting (even if they currently do backport in svn). So with the new workflow, even more patches will be forgotten wrt. backporting. It would still be possible that somebody else backports for them, but that will be more tedious than it is now with svnmerge (since you first have to transplant, and then merge back the transplanted patch, which should come out as a no-op - but the merge must be recorded). Regards, Martin From martin at v.loewis.de Sat Feb 5 02:32:02 2011 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Sat, 05 Feb 2011 02:32:02 +0100 Subject: [python-committers] =?iso-8859-1?q?=5BPSF-Members=5D_Code_Simplic?= =?iso-8859-1?q?ity_=BB_Open_Source_Community=2C_Simplified?= In-Reply-To: <4D4C483C.1060101@jcea.es> References: <4D495CBA.6040706@python.org> <20110202114702.133c59de@python.org> <4D4993C2.9080909@jcea.es> <1296668327.3718.8.camel@localhost.localdomain> <4D49A093.4020909@jcea.es> <1296671319.3718.9.camel@localhost.localdomain> <4D49A4D0.8070908@jcea.es> <1296672429.3718.12.camel@localhost.localdomain> <4D49BC33.3030706@jcea.es> <20110202153001.527be580@python.org> <4D49F8CD.90807@jcea.es> <4D4B6E28.4010209@jcea.es> <1296822354.3774.3.camel@localhost.localdomain> <20110204143019.5B3DB241BF5@kimball.webabinitio.net> <1296837094.3774.10.camel@localhost.localdomain> <4D4C483C.1060101@jcea.es> Message-ID: <4D4CA892.7010202@v.loewis.de> Am 04.02.2011 19:41, schrieb Jesus Cea: > On 04/02/11 17:31, Antoine Pitrou wrote: >> How do you "block"? > > What patches in "3.2" you don't want in "3.3"?. It happens in more cases than you think. I sometimes develop two versions of a patch, one for the maintenance branch which preserves backwards compatibility, and another version that fixes it in the right way. I think I regularly contributes two or three such changes to every feature release of Python. I think a few other committers have also written such changes over time. Regards, Martin From ncoghlan at gmail.com Sat Feb 5 09:34:04 2011 From: ncoghlan at gmail.com (Nick Coghlan) Date: Sat, 5 Feb 2011 18:34:04 +1000 Subject: [python-committers] =?iso-8859-1?q?=5BPSF-Members=5D_Code_Simplic?= =?iso-8859-1?q?ity_=BB_Open_Source_Community=2C_Simplified?= In-Reply-To: <4D4C931E.5030709@jcea.es> References: <4D495CBA.6040706@python.org> <20110202114702.133c59de@python.org> <4D4993C2.9080909@jcea.es> <1296668327.3718.8.camel@localhost.localdomain> <4D49A093.4020909@jcea.es> <1296671319.3718.9.camel@localhost.localdomain> <4D49A4D0.8070908@jcea.es> <1296672429.3718.12.camel@localhost.localdomain> <4D49BC33.3030706@jcea.es> <20110202153001.527be580@python.org> <4D49F8CD.90807@jcea.es> <4D4B6E28.4010209@jcea.es> <1296822354.3774.3.camel@localhost.localdomain> <20110204143019.5B3DB241BF5@kimball.webabinitio.net> <1296837094.3774.10.camel@localhost.localdomain> <4D4C483C.1060101@jcea.es> <4D4C599A.9090205@udel.edu> <4D4C8A85.9090405@jcea.es> <1296862592.3774.17.camel@localhost.localdomain> <4D4C931E.5030709@jcea.es> Message-ID: On Sat, Feb 5, 2011 at 10:00 AM, Jesus Cea wrote: > 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 :). Work = CVS, Python = SVN, ??? = Hg. I don't believe you can genuinely learn any VCS until you use it for serious work, and there's simply nothing I work on currently that stresses the abilities of Hg. (The extent of my Hg usage is playing with the commit hooks and devguide repositories on hg.python.org). I've read plenty about it, and have a reasonable idea of how it works, but a lot of the things I've read about the recommended workflows simply don't line up with the way we have historically done things. As I've said, I'm happy to roll with that, but I consider the onus to be on the champions of the Mercurial switchover to document the best workflows they can collectively come up with for the benefit of those of us that are Mercurial novices. What we have with SVN certainly has its problems, but it mostly works and we're used to it. A wildly divergent 2.7 branch, with a 3.3 development branch, a 3.2 maintenance branch, 2.6 and 3.1 security branches and assorted feature branches is going to be plenty to be going on with, even before we get to the question of managing the 3.3 release in mid-to-late 2012. Consider the day of the switchover, when SVN has gone read-only and Hg is opened up for pushes. What should I have checked out on my machine in advance in order to work on: 1. PEPs 2. The dev guide 3. New 3.x features 4. 3.x only bug fixes 5. Bug fixes that also apply to 2.7 6. Security fixes that apply to 3.1/2.6 7. A feature-specific branch I'm happy to be guided by the Hg veterans here, *but the Hg veterans need to be willing to document their advice in a common location and come to consensus on it*. Cheers, Nick. -- Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia From rdmurray at bitdance.com Sat Feb 5 19:08:50 2011 From: rdmurray at bitdance.com (R. David Murray) Date: Sat, 05 Feb 2011 13:08:50 -0500 Subject: [python-committers] =?iso-8859-1?q?=5BPSF-Members=5D_Code_Simplic?= =?iso-8859-1?q?ity_=BB_Open_Source_Community=2C_Simplified?= In-Reply-To: <4D4CA2E8.3030506@v.loewis.de> References: <4D495CBA.6040706@python.org> <20110202114702.133c59de@python.org> <4D4993C2.9080909@jcea.es> <1296668327.3718.8.camel@localhost.localdomain> <4D49A093.4020909@jcea.es> <1296671319.3718.9.camel@localhost.localdomain> <4D49A4D0.8070908@jcea.es> <1296672429.3718.12.camel@localhost.localdomain> <4D49BC33.3030706@jcea.es> <20110202153001.527be580@python.org> <4D4CA2E8.3030506@v.loewis.de> Message-ID: <20110205180851.0E3EC21DC0B@kimball.webabinitio.net> On Sat, 05 Feb 2011 02:07:52 +0100, wrote: > > Indeed. Mainline is the only branch where we *know* most patches need > > to be applied. It also means that people can contribute while > > maintaining only a single checkout, rather than necessarily needing > > all active versions. > > Notice that you'll automatically will have all active versions > available, if PEP 385 is implemented. A single clone will have all > maintenance branches as named branches inside, so integrating > a bug fix should be a sequence like > > hg update release32-maint > patch > hg commit > hg update default > hg merge release32-maint > hg commit -m merged > hg push > > Sprinkle test runs into this to your taste. What about compiles? And perhaps even make distclean/configure? With our current workflow I have separate checkouts for 2.7, 3.1, and 3.2, and run make when I see a c file go by after an svn up (and make distclean if I see an update to a .in file, though I know that isn't always necessary). Is there a way to translate that bit of the workflow to hg, or do I need to run make after each update, and make distclean if things fail to work as expected? Will running make after an update always do the right thing (ignoring those issues for which make distclean is currently needed)? We really really really need some to document the expected best practices. Even if there isn't agreement among the hg veterans yet, someone should document *something* that we can iterate on to reach a preliminary consensus so us newbies have something to work from when the switchover is made. I'm with Nick here; I don't have a project that uses hg, and until I do no amount of reading about it is going to do any good. And even after I'm going to need help...I tried using bzr for email6 and I *still* don't understand how to use it properly. Of course, nobody had written a best practices guide for me for my project, which is why I'm joining the chorus asking for one for Python :) -- R. David Murray www.bitdance.com From brett at python.org Sat Feb 5 20:44:05 2011 From: brett at python.org (Brett Cannon) Date: Sat, 5 Feb 2011 11:44:05 -0800 Subject: [python-committers] =?utf-8?q?=5BPSF-Members=5D_Code_Simplicity_?= =?utf-8?q?=C2=BB_Open_Source_Community=2C_Simplified?= In-Reply-To: <20110205180851.0E3EC21DC0B@kimball.webabinitio.net> References: <4D495CBA.6040706@python.org> <20110202114702.133c59de@python.org> <4D4993C2.9080909@jcea.es> <1296668327.3718.8.camel@localhost.localdomain> <4D49A093.4020909@jcea.es> <1296671319.3718.9.camel@localhost.localdomain> <4D49A4D0.8070908@jcea.es> <1296672429.3718.12.camel@localhost.localdomain> <4D49BC33.3030706@jcea.es> <20110202153001.527be580@python.org> <4D4CA2E8.3030506@v.loewis.de> <20110205180851.0E3EC21DC0B@kimball.webabinitio.net> Message-ID: Just to help settle this, I will write something and work with the appropriate people to get something worked out. I will most likely branch the devguide with an hg_transition branch and work in there so people can still publicly participate but not have it affect the published site. On Sat, Feb 5, 2011 at 10:08, R. David Murray wrote: > On Sat, 05 Feb 2011 02:07:52 +0100, wrote: >> > Indeed. Mainline is the only branch where we *know* most patches need >> > to be applied. It also means that people can contribute while >> > maintaining only a single checkout, rather than necessarily needing >> > all active versions. >> >> Notice that you'll automatically will have all active versions >> available, if PEP 385 is implemented. A single clone will have all >> maintenance branches as named branches inside, so integrating >> a bug fix should be a sequence like >> >> hg update release32-maint >> patch >> hg commit >> hg update default >> hg merge release32-maint >> hg commit -m merged >> hg push >> >> Sprinkle test runs into this to your taste. > > What about compiles? ?And perhaps even make distclean/configure? ?With our > current workflow I have separate checkouts for 2.7, 3.1, and 3.2, and > run make when I see a c file go by after an svn up (and make distclean if > I see an update to a .in file, though I know that isn't always necessary). > > Is there a way to translate that bit of the workflow to hg, or do I need > to run make after each update, and make distclean if things fail to work > as expected? ?Will running make after an update always do the right thing > (ignoring those issues for which make distclean is currently needed)? > > We really really really need some to document the expected best practices. > Even if there isn't agreement among the hg veterans yet, someone should > document *something* that we can iterate on to reach a preliminary > consensus so us newbies have something to work from when the switchover > is made. > > I'm with Nick here; I don't have a project that uses hg, and until I do > no amount of reading about it is going to do any good. ?And even after > I'm going to need help...I tried using bzr for email6 and I *still* > don't understand how to use it properly. ?Of course, nobody had written > a best practices guide for me for my project, which is why I'm joining > the chorus asking for one for Python :) > > -- > R. David Murray ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?www.bitdance.com > _______________________________________________ > python-committers mailing list > python-committers at python.org > http://mail.python.org/mailman/listinfo/python-committers > From martin at v.loewis.de Sat Feb 5 21:12:37 2011 From: martin at v.loewis.de (=?ISO-8859-15?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Sat, 05 Feb 2011 21:12:37 +0100 Subject: [python-committers] =?iso-8859-15?q?=5BPSF-Members=5D_Code_Simpli?= =?iso-8859-15?q?city_=BB_Open_Source_Community=2C_Simplified?= In-Reply-To: <20110205180851.0E3EC21DC0B@kimball.webabinitio.net> References: <4D495CBA.6040706@python.org> <20110202114702.133c59de@python.org> <4D4993C2.9080909@jcea.es> <1296668327.3718.8.camel@localhost.localdomain> <4D49A093.4020909@jcea.es> <1296671319.3718.9.camel@localhost.localdomain> <4D49A4D0.8070908@jcea.es> <1296672429.3718.12.camel@localhost.localdomain> <4D49BC33.3030706@jcea.es> <20110202153001.527be580@python.org> <4D4CA2E8.3030506@v.loewis.de> <20110205180851.0E3EC21DC0B@kimball.webabinitio.net> Message-ID: <4D4DAF35.4010705@v.loewis.de> >> hg update release32-maint >> patch >> hg commit >> hg update default >> hg merge release32-maint >> hg commit -m merged >> hg push >> >> Sprinkle test runs into this to your taste. > > What about compiles? Good question; this is beyond my hg-FU. Approaches that might be worth trying are: - have separate build directories, all referring to the same source directory. Python currently doesn't fully support that (i.e. there are cases when the source directory is changed), but people have been asking that this gets supported for a long time. - share repositories across multiple checkouts, using symlinks. Not sure whether this is supported. - Make local clones, one per branch, and then push across them. E.g. the flow might change to cd 32 hg pull -u upstream patch build hg commit cd ../trunk hg pull 32 hg merge build hg commit -m merge hg push upstream Notice that the push and the pull come from different clones: you would pull into the 3.2 clone, and eventually push from the trunk clone. As for the "32" references above: the first one is a directory; the second is a named source (from ..hg/hgrc). Not sure whether "hg pull ../32" would work as well. > And perhaps even make distclean/configure? With our > current workflow I have separate checkouts for 2.7, 3.1, and 3.2, and > run make when I see a c file go by after an svn up (and make distclean if > I see an update to a .in file, though I know that isn't always necessary). At least the third one should be identical to your current setup, except that a) changes flow into the other direction, and b) there is no server communication to move patches across branches (whereas in subversion, you commit to the server, then svnmerge from the server). Regards, Martin From brett at python.org Sun Feb 6 04:21:55 2011 From: brett at python.org (Brett Cannon) Date: Sat, 5 Feb 2011 19:21:55 -0800 Subject: [python-committers] =?utf-8?q?=5BPSF-Members=5D_Code_Simplicity_?= =?utf-8?q?=C2=BB_Open_Source_Community=2C_Simplified?= In-Reply-To: References: <4D495CBA.6040706@python.org> <20110202114702.133c59de@python.org> <4D4993C2.9080909@jcea.es> <1296668327.3718.8.camel@localhost.localdomain> <4D49A093.4020909@jcea.es> <1296671319.3718.9.camel@localhost.localdomain> <4D49A4D0.8070908@jcea.es> <1296672429.3718.12.camel@localhost.localdomain> <4D49BC33.3030706@jcea.es> <20110202153001.527be580@python.org> <4D4CA2E8.3030506@v.loewis.de> <20110205180851.0E3EC21DC0B@kimball.webabinitio.net> Message-ID: I started the branch, so any commits to the devguide mentiong hg, you can rest assured they are not going to the live site. =) I will get a workflow written up and then email the people I know who are already heavy hg users (Antoine, Georg, and Dirkjan; if you want to be included in the discussion let me know) to read it over. Once we have agreed that the docs as written are accurate and we think they are best practices for what we want, I will let python-committers know and people can have a look to make sure everything is clear and easy to understand for when the transition occurs. This will also give Nick a chance to make sure the dev FAQ is ready to go since he wanted it kept alive. =) On Sat, Feb 5, 2011 at 11:44, Brett Cannon wrote: > Just to help settle this, I will write something and work with the > appropriate people to get something worked out. I will most likely > branch the devguide with an hg_transition branch and work in there so > people can still publicly participate but not have it affect the > published site. > > On Sat, Feb 5, 2011 at 10:08, R. David Murray wrote: >> On Sat, 05 Feb 2011 02:07:52 +0100, wrote: >>> > Indeed. Mainline is the only branch where we *know* most patches need >>> > to be applied. It also means that people can contribute while >>> > maintaining only a single checkout, rather than necessarily needing >>> > all active versions. >>> >>> Notice that you'll automatically will have all active versions >>> available, if PEP 385 is implemented. A single clone will have all >>> maintenance branches as named branches inside, so integrating >>> a bug fix should be a sequence like >>> >>> hg update release32-maint >>> patch >>> hg commit >>> hg update default >>> hg merge release32-maint >>> hg commit -m merged >>> hg push >>> >>> Sprinkle test runs into this to your taste. >> >> What about compiles? ?And perhaps even make distclean/configure? ?With our >> current workflow I have separate checkouts for 2.7, 3.1, and 3.2, and >> run make when I see a c file go by after an svn up (and make distclean if >> I see an update to a .in file, though I know that isn't always necessary). >> >> Is there a way to translate that bit of the workflow to hg, or do I need >> to run make after each update, and make distclean if things fail to work >> as expected? ?Will running make after an update always do the right thing >> (ignoring those issues for which make distclean is currently needed)? >> >> We really really really need some to document the expected best practices. >> Even if there isn't agreement among the hg veterans yet, someone should >> document *something* that we can iterate on to reach a preliminary >> consensus so us newbies have something to work from when the switchover >> is made. >> >> I'm with Nick here; I don't have a project that uses hg, and until I do >> no amount of reading about it is going to do any good. ?And even after >> I'm going to need help...I tried using bzr for email6 and I *still* >> don't understand how to use it properly. ?Of course, nobody had written >> a best practices guide for me for my project, which is why I'm joining >> the chorus asking for one for Python :) >> >> -- >> R. David Murray ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?www.bitdance.com >> _______________________________________________ >> python-committers mailing list >> python-committers at python.org >> http://mail.python.org/mailman/listinfo/python-committers >> > From jcea at jcea.es Sun Feb 6 05:11:37 2011 From: jcea at jcea.es (Jesus Cea) Date: Sun, 06 Feb 2011 05:11:37 +0100 Subject: [python-committers] =?iso-8859-15?q?=5BPSF-Members=5D_Code_Simpli?= =?iso-8859-15?q?city_=BB_Open_Source_Community=2C_Simplified?= In-Reply-To: References: <4D495CBA.6040706@python.org> <20110202114702.133c59de@python.org> <4D4993C2.9080909@jcea.es> <1296668327.3718.8.camel@localhost.localdomain> <4D49A093.4020909@jcea.es> <1296671319.3718.9.camel@localhost.localdomain> <4D49A4D0.8070908@jcea.es> <1296672429.3718.12.camel@localhost.localdomain> <4D49BC33.3030706@jcea.es> <20110202153001.527be580@python.org> <4D4CA2E8.3030506@v.loewis.de> <20110205180851.0E3EC21DC0B@kimball.webabinitio.net> Message-ID: <4D4E1F79.4030800@jcea.es> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/02/11 04:21, Brett Cannon wrote: > I will get a workflow written up and then email the people I know who > are already heavy hg users (Antoine, Georg, and Dirkjan; if you want > to be included in the discussion let me know) to read it over. Could I read it too?. I have been using HG for the last three years, at least. - -- 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/ iQCVAwUBTU4feZlgi5GaxT1NAQIJmQP+IdVCtga5lt+qFxnGJZMXdi4nB2YIuc/4 ZIJypIFzm0W3WDzxG5THysI+h0CtmWgUgXnbL4Tshm68sAJpcsNY0FTXvtlHQtsG 7JvDRa/9vsC2sBEnHdhxm+HZusCgesd45cS8tFF1fRuO/WSGI38vjM46YNU2m1kH EHhkSzFbmeE= =dZQQ -----END PGP SIGNATURE----- From ncoghlan at gmail.com Sun Feb 6 06:17:14 2011 From: ncoghlan at gmail.com (Nick Coghlan) Date: Sun, 6 Feb 2011 15:17:14 +1000 Subject: [python-committers] =?iso-8859-1?q?=5BPSF-Members=5D_Code_Simplic?= =?iso-8859-1?q?ity_=BB_Open_Source_Community=2C_Simplified?= In-Reply-To: <4D4E1F79.4030800@jcea.es> References: <4D495CBA.6040706@python.org> <20110202114702.133c59de@python.org> <4D4993C2.9080909@jcea.es> <1296668327.3718.8.camel@localhost.localdomain> <4D49A093.4020909@jcea.es> <1296671319.3718.9.camel@localhost.localdomain> <4D49A4D0.8070908@jcea.es> <1296672429.3718.12.camel@localhost.localdomain> <4D49BC33.3030706@jcea.es> <20110202153001.527be580@python.org> <4D4CA2E8.3030506@v.loewis.de> <20110205180851.0E3EC21DC0B@kimball.webabinitio.net> <4D4E1F79.4030800@jcea.es> Message-ID: On Sun, Feb 6, 2011 at 2:11 PM, Jesus Cea wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 06/02/11 04:21, Brett Cannon wrote: >> I will get a workflow written up and then email the people I know who >> are already heavy hg users (Antoine, Georg, and Dirkjan; if you want >> to be included in the discussion let me know) to read it over. > > Could I read it too?. I have been using HG for the last three years, at > least. I don't believe the formatted HTML is being published anywhere at this stage, but the raw ReST files are available from the Hg repository: http://hg.python.org/devguide/branches Cheers, Nick. -- Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia From ncoghlan at gmail.com Sun Feb 6 06:27:50 2011 From: ncoghlan at gmail.com (Nick Coghlan) Date: Sun, 6 Feb 2011 15:27:50 +1000 Subject: [python-committers] =?iso-8859-1?q?=5BPSF-Members=5D_Code_Simplic?= =?iso-8859-1?q?ity_=BB_Open_Source_Community=2C_Simplified?= In-Reply-To: References: <4D495CBA.6040706@python.org> <20110202114702.133c59de@python.org> <4D4993C2.9080909@jcea.es> <1296668327.3718.8.camel@localhost.localdomain> <4D49A093.4020909@jcea.es> <1296671319.3718.9.camel@localhost.localdomain> <4D49A4D0.8070908@jcea.es> <1296672429.3718.12.camel@localhost.localdomain> <4D49BC33.3030706@jcea.es> <20110202153001.527be580@python.org> <4D4CA2E8.3030506@v.loewis.de> <20110205180851.0E3EC21DC0B@kimball.webabinitio.net> Message-ID: On Sun, Feb 6, 2011 at 1:21 PM, Brett Cannon wrote: > This will also give Nick a chance to make sure the dev FAQ is ready to > go since he wanted it kept alive. =) Sure, I can do that. If there is anything I can't figure out I'll leave a placeholder for someone with greater hg-fu to fill in. Cheers, Nick. -- Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia From stutzbach at google.com Mon Feb 7 18:25:15 2011 From: stutzbach at google.com (Daniel Stutzbach) Date: Mon, 7 Feb 2011 09:25:15 -0800 Subject: [python-committers] =?utf-8?q?=5BPSF-Members=5D_Code_Simplicity_?= =?utf-8?q?=C2=BB_Open_Source_Community=2C_Simplified?= In-Reply-To: <4D4DAF35.4010705@v.loewis.de> References: <4D495CBA.6040706@python.org> <20110202114702.133c59de@python.org> <4D4993C2.9080909@jcea.es> <1296668327.3718.8.camel@localhost.localdomain> <4D49A093.4020909@jcea.es> <1296671319.3718.9.camel@localhost.localdomain> <4D49A4D0.8070908@jcea.es> <1296672429.3718.12.camel@localhost.localdomain> <4D49BC33.3030706@jcea.es> <20110202153001.527be580@python.org> <4D4CA2E8.3030506@v.loewis.de> <20110205180851.0E3EC21DC0B@kimball.webabinitio.net> <4D4DAF35.4010705@v.loewis.de> Message-ID: On Sat, Feb 5, 2011 at 12:12 PM, "Martin v. L?wis" wrote: > - Make local clones, one per branch, and then push across them. > Like Victor, I have been using git to talk to the Python SVN servers for some time now. I have been using the strategy Martin proposes here with great success. I seem to recall reading that hg makes cheap clones by using hard links for files that are the same in both clones (i.e., the common revision history before they branched). -- Daniel Stutzbach -------------- next part -------------- An HTML attachment was scrubbed... URL: From solipsis at pitrou.net Mon Feb 7 18:29:47 2011 From: solipsis at pitrou.net (Antoine Pitrou) Date: Mon, 07 Feb 2011 18:29:47 +0100 Subject: [python-committers] Mercurial In-Reply-To: References: <4D495CBA.6040706@python.org> <20110202114702.133c59de@python.org> <4D4993C2.9080909@jcea.es> <1296668327.3718.8.camel@localhost.localdomain> <4D49A093.4020909@jcea.es> <1296671319.3718.9.camel@localhost.localdomain> <4D49A4D0.8070908@jcea.es> <1296672429.3718.12.camel@localhost.localdomain> <4D49BC33.3030706@jcea.es> <20110202153001.527be580@python.org> <4D4CA2E8.3030506@v.loewis.de> <20110205180851.0E3EC21DC0B@kimball.webabinitio.net> <4D4DAF35.4010705@v.loewis.de> Message-ID: <1297099787.3754.29.camel@localhost.localdomain> Le lundi 07 f?vrier 2011 ? 09:25 -0800, Daniel Stutzbach a ?crit : > On Sat, Feb 5, 2011 at 12:12 PM, "Martin v. L?wis" > wrote: > - Make local clones, one per branch, and then push across > them. > > > Like Victor, I have been using git to talk to the Python SVN servers > for some time now. I have been using the strategy Martin proposes > here with great success. > > > I seem to recall reading that hg makes cheap clones by using hard > links for files that are the same in both clones (i.e., the common > revision history before they branched). It does. And since CPython is fast to compile, it is quite a reasonable method. Anyone wanting to know more about hg should try to read (at least part of) http://hgbook.red-bean.com/ . Also, I've finished converting (after Nick started it) the developer's FAQ to display instructions for hg. Reviewing it is welcome; I put a build here: http://potrou.net/hgdevguide/faq.html Regards Antoine. From ncoghlan at gmail.com Tue Feb 8 15:27:21 2011 From: ncoghlan at gmail.com (Nick Coghlan) Date: Wed, 9 Feb 2011 00:27:21 +1000 Subject: [python-committers] Mercurial In-Reply-To: <1297099787.3754.29.camel@localhost.localdomain> References: <4D495CBA.6040706@python.org> <20110202114702.133c59de@python.org> <4D4993C2.9080909@jcea.es> <1296668327.3718.8.camel@localhost.localdomain> <4D49A093.4020909@jcea.es> <1296671319.3718.9.camel@localhost.localdomain> <4D49A4D0.8070908@jcea.es> <1296672429.3718.12.camel@localhost.localdomain> <4D49BC33.3030706@jcea.es> <20110202153001.527be580@python.org> <4D4CA2E8.3030506@v.loewis.de> <20110205180851.0E3EC21DC0B@kimball.webabinitio.net> <4D4DAF35.4010705@v.loewis.de> <1297099787.3754.29.camel@localhost.localdomain> Message-ID: On Tue, Feb 8, 2011 at 3:29 AM, Antoine Pitrou wrote: > Also, I've finished converting (after Nick started it) the developer's > FAQ to display instructions for hg. Reviewing it is welcome; I put a > build here: > http://potrou.net/hgdevguide/faq.html Thanks for that - it definitely gives us a solid base to start from. If we get any repetitive questions after the transition happens, we can add the answers to the FAQ then. Cheers, Nick. -- Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia From g.brandl at gmx.net Wed Feb 9 08:41:06 2011 From: g.brandl at gmx.net (Georg Brandl) Date: Wed, 09 Feb 2011 08:41:06 +0100 Subject: [python-committers] 3.2rc3 on weekend Message-ID: Since py3k has seen quite a few commits since rc2, I'd like to be on the safe side and put in an rc3 this weekend, with the final postponed by one week. (Just a heads-up, there shouldn't be anything different for non-release-managers/experts as I hope for a commit-less week). Georg From vinay_sajip at yahoo.co.uk Sat Feb 12 15:28:53 2011 From: vinay_sajip at yahoo.co.uk (Vinay Sajip) Date: Sat, 12 Feb 2011 14:28:53 +0000 (UTC) Subject: [python-committers] py3k frozen for rc2 References: <4D4534CE.4010509@python.org> <4D45CE49.8010909@python.org> Message-ID: Hi Georg, Georg Brandl python.org> writes: > Am 30.01.2011 10:52, schrieb Georg Brandl: > > Okay, this is it: please no more commits to the py3k branch for now. > > > > Also, for the remainder of the time until final, please make sure there > > is an issue for each change you want to make containing the patch > > (which was already the case for almost all changes after rc1 anyway), > > and assign the issue to me for sign-off after review. > > > > Changes to the "What's new" are exempt, but I would love some volunteers > > to read through the document and note any issues or typos. > > OK, the branch is now unfrozen again, but please remember the policy > above. > Does this apply to doc changes, too? I want to make some additions to the SocketHandler docs - about functionality which has been in there for a long time but, due to an oversight, never got documented. Since it's long overdue, it can certainly wait a little longer :-) Regards, Vinay Sajip From g.brandl at gmx.net Sun Feb 13 00:02:41 2011 From: g.brandl at gmx.net (Georg Brandl) Date: Sun, 13 Feb 2011 00:02:41 +0100 Subject: [python-committers] py3k frozen for rc2 In-Reply-To: References: <4D4534CE.4010509@python.org> <4D45CE49.8010909@python.org> Message-ID: Am 12.02.2011 15:28, schrieb Vinay Sajip: > Hi Georg, > > Georg Brandl python.org> writes: > >> Am 30.01.2011 10:52, schrieb Georg Brandl: >> > Okay, this is it: please no more commits to the py3k branch for now. >> > >> > Also, for the remainder of the time until final, please make sure there >> > is an issue for each change you want to make containing the patch >> > (which was already the case for almost all changes after rc1 anyway), >> > and assign the issue to me for sign-off after review. >> > >> > Changes to the "What's new" are exempt, but I would love some volunteers >> > to read through the document and note any issues or typos. >> >> OK, the branch is now unfrozen again, but please remember the policy >> above. >> > > Does this apply to doc changes, too? I want to make some additions to the > SocketHandler docs - about functionality which has been in there for a long time > but, due to an oversight, never got documented. Since it's long overdue, it can > certainly wait a little longer :-) If you can manage, it would be nice to upload the patch somewhere and let me review it quickly. Georg From g.brandl at gmx.net Sun Feb 13 10:58:30 2011 From: g.brandl at gmx.net (Georg Brandl) Date: Sun, 13 Feb 2011 10:58:30 +0100 Subject: [python-committers] py3k frozen for rc3 Message-ID: Since there are no remaining blockers (real or deferred), the py3k branch is now frozen for the rc3 release, and subsequently will remain frozen until the final, unless critical bugs are uncovered. Any checkin that is to be made must be made by either me or one of the experts (Windows, Mac, What's New). Thanks for your patience, Georg From vinay_sajip at yahoo.co.uk Sun Feb 13 13:22:46 2011 From: vinay_sajip at yahoo.co.uk (Vinay Sajip) Date: Sun, 13 Feb 2011 12:22:46 +0000 (UTC) Subject: [python-committers] py3k frozen for rc2 References: <4D4534CE.4010509@python.org> <4D45CE49.8010909@python.org> Message-ID: Georg Brandl gmx.net> writes: > If you can manage, it would be nice to upload the patch somewhere and > let me review it quickly. Here's the patch: https://gist.github.com/824644 I know you'll be busy so I completely understand if you don't have time to review it :-) Thanks, Vinay Sajip From orsenthil at gmail.com Sun Feb 13 14:42:39 2011 From: orsenthil at gmail.com (Senthil Kumaran) Date: Sun, 13 Feb 2011 21:42:39 +0800 Subject: [python-committers] py3k frozen for rc2 In-Reply-To: References: <4D4534CE.4010509@python.org> <4D45CE49.8010909@python.org> Message-ID: <20110213134239.GA12042@ubuntu> On Sun, Feb 13, 2011 at 12:22:46PM +0000, Vinay Sajip wrote: > Here's the patch: > > https://gist.github.com/824644 > I think you missed the rc3 freeze email. :) -- Senthil From mfoord at python.org Sun Feb 13 14:44:05 2011 From: mfoord at python.org (Michael Foord) Date: Sun, 13 Feb 2011 13:44:05 +0000 Subject: [python-committers] py3k frozen for rc2 In-Reply-To: <20110213134239.GA12042@ubuntu> References: <4D4534CE.4010509@python.org> <4D45CE49.8010909@python.org> <20110213134239.GA12042@ubuntu> Message-ID: <4D57E025.5010604@python.org> On 13/02/2011 13:42, Senthil Kumaran wrote: > On Sun, Feb 13, 2011 at 12:22:46PM +0000, Vinay Sajip wrote: >> Here's the patch: >> >> https://gist.github.com/824644 >> > I think you missed the rc3 freeze email. :) > It's just a doc patch that Georg gave permission for - or did you mean something else? Michael -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html From g.brandl at gmx.net Sun Feb 13 15:23:48 2011 From: g.brandl at gmx.net (Georg Brandl) Date: Sun, 13 Feb 2011 15:23:48 +0100 Subject: [python-committers] py3k frozen for rc2 In-Reply-To: <20110213134239.GA12042@ubuntu> References: <4D4534CE.4010509@python.org> <4D45CE49.8010909@python.org> <20110213134239.GA12042@ubuntu> Message-ID: Am 13.02.2011 14:42, schrieb Senthil Kumaran: > On Sun, Feb 13, 2011 at 12:22:46PM +0000, Vinay Sajip wrote: >> Here's the patch: >> >> https://gist.github.com/824644 >> > > I think you missed the rc3 freeze email. :) He didn't actually commit it, but I will do after rc3 is out the door. Georg From orsenthil at gmail.com Sun Feb 13 15:16:14 2011 From: orsenthil at gmail.com (Senthil Kumaran) Date: Sun, 13 Feb 2011 22:16:14 +0800 Subject: [python-committers] py3k frozen for rc2 In-Reply-To: <4D57E025.5010604@python.org> References: <4D4534CE.4010509@python.org> <4D45CE49.8010909@python.org> <20110213134239.GA12042@ubuntu> <4D57E025.5010604@python.org> Message-ID: On Sun, Feb 13, 2011 at 9:44 PM, Michael Foord wrote: > On 13/02/2011 13:42, Senthil Kumaran wrote: >> >> On Sun, Feb 13, 2011 at 12:22:46PM +0000, Vinay Sajip wrote: >>> >>> Here's the patch: >>> >>> https://gist.github.com/824644 >>> >> I think you missed the rc3 freeze email. :) >> > It's just a doc patch that Georg gave permission for - or did you mean > something else? Oh, I had not check the contents of the patch. But I followed the discussion and timeline for this thread which was relevant for rc2. Georg had sent the rc3 freeze email just before this (which had some strict criteria on changes which can go in) and I thought Vinay missed that email. -- Senthil From georg at python.org Mon Feb 14 07:40:00 2011 From: georg at python.org (Georg Brandl) Date: Mon, 14 Feb 2011 07:40:00 +0100 Subject: [python-committers] [RELEASED] Python 3.2 rc 3 Message-ID: <4D58CE40.1010408@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On behalf of the Python development team, I'm happy to announce the third release candidate of Python 3.2. Python 3.2 is a continuation of the efforts to improve and stabilize the Python 3.x line. Since the final release of Python 2.7, the 2.x line will only receive bugfixes, and new features are developed for 3.x only. Since PEP 3003, the Moratorium on Language Changes, is in effect, there are no changes in Python's syntax and built-in types in Python 3.2. Development efforts concentrated on the standard library and support for porting code to Python 3. Highlights are: * numerous improvements to the unittest module * PEP 3147, support for .pyc repository directories * PEP 3149, support for version tagged dynamic libraries * PEP 3148, a new futures library for concurrent programming * PEP 384, a stable ABI for extension modules * PEP 391, dictionary-based logging configuration * an overhauled GIL implementation that reduces contention * an extended email package that handles bytes messages * a much improved ssl module with support for SSL contexts and certificate hostname matching * a sysconfig module to access configuration information * additions to the shutil module, among them archive file support * many enhancements to configparser, among them mapping protocol support * improvements to pdb, the Python debugger * countless fixes regarding bytes/string issues; among them full support for a bytes environment (filenames, environment variables) * many consistency and behavior fixes for numeric operations For a more extensive list of changes in 3.2, see http://docs.python.org/3.2/whatsnew/3.2.html To download Python 3.2 visit: http://www.python.org/download/releases/3.2/ Please consider trying Python 3.2 with your code and reporting any bugs you may notice to: http://bugs.python.org/ Enjoy! - -- Georg Brandl, Release Manager georg at python.org (on behalf of the entire python-dev team and 3.2's contributors) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk1YzkAACgkQN9GcIYhpnLAggwCfQ92djMinrmNkGI4Ma3VRqrcX EWIAn16kTEJtvEH/7DJApp7YdhnmIRBd =NJ1B -----END PGP SIGNATURE----- From g.brandl at gmx.net Wed Feb 16 18:53:41 2011 From: g.brandl at gmx.net (Georg Brandl) Date: Wed, 16 Feb 2011 18:53:41 +0100 Subject: [python-committers] Unavailable for two days Message-ID: I'll be mostly away from internet for Thursday and Friday, so if any release-critical issues pop up, please don't be surprised if I don't react promptly. I'll be back on Saturday, to sort out any remaining issues, and the release will be done on Sunday. Georg From brett at python.org Fri Feb 18 21:36:44 2011 From: brett at python.org (Brett Cannon) Date: Fri, 18 Feb 2011 12:36:44 -0800 Subject: [python-committers] do we still believe explicit relative imports are bad as PEP 8 claims? Message-ID: It says they are "highly discouraged" because "absolute imports are more portable and usually more readable", but now that people have had a chance to use explicit relative imports, do people still believe this? I mean if we truly believed this then why did we add the syntax? I know I have used it and love it, let alone that I don't buy the portability argument. From fdrake at acm.org Fri Feb 18 21:53:39 2011 From: fdrake at acm.org (Fred Drake) Date: Fri, 18 Feb 2011 15:53:39 -0500 Subject: [python-committers] do we still believe explicit relative imports are bad as PEP 8 claims? In-Reply-To: References: Message-ID: On Fri, Feb 18, 2011 at 3:36 PM, Brett Cannon wrote: > It says they are "highly discouraged" because "absolute imports are > more portable and usually more readable", but now that people have had > a chance to use explicit relative imports, do people still believe > this? I mean if we truly believed this then why did we add the syntax? > I know I have used it and love it, let alone that I don't buy the > portability argument. I suspect the portability argument is about cross-Python-version compatibility, rather than across operating systems. Maybe we don't care about that any more since 2.4 and earlier don't exist in the eyes of python-dev. On the other hand, I've never used them, or stumbled over code that does, so I won't speak to the readability issue. I have an opinion, but no practical experience with explicit relative imports. ? -Fred -- Fred L. Drake, Jr.? ? "A storm broke loose in my mind."? --Albert Einstein From solipsis at pitrou.net Fri Feb 18 21:59:27 2011 From: solipsis at pitrou.net (Antoine Pitrou) Date: Fri, 18 Feb 2011 21:59:27 +0100 Subject: [python-committers] do we still believe explicit relative imports are bad as PEP 8 claims? In-Reply-To: References: Message-ID: <1298062767.3761.16.camel@localhost.localdomain> Le vendredi 18 f?vrier 2011 ? 12:36 -0800, Brett Cannon a ?crit : > It says they are "highly discouraged" because "absolute imports are > more portable and usually more readable", but now that people have had > a chance to use explicit relative imports, do people still believe > this? I mean if we truly believed this then why did we add the syntax? > I know I have used it and love it, let alone that I don't buy the > portability argument. I personally find it confusing and unreadable, and I much prefer when I don't have to decipher it (especially non-trivial variants such as "from ..foo import bar"). Just my 2 cents Antoine. From fdrake at acm.org Fri Feb 18 22:15:33 2011 From: fdrake at acm.org (Fred Drake) Date: Fri, 18 Feb 2011 16:15:33 -0500 Subject: [python-committers] do we still believe explicit relative imports are bad as PEP 8 claims? In-Reply-To: <1298062767.3761.16.camel@localhost.localdomain> References: <1298062767.3761.16.camel@localhost.localdomain> Message-ID: On Fri, Feb 18, 2011 at 3:59 PM, Antoine Pitrou wrote: > (especially non-trivial variants such as "from ..foo import bar"). Eeewe. More than one leading "." should be considered a bug. ? -Fred -- Fred L. Drake, Jr.? ? "A storm broke loose in my mind."? --Albert Einstein From mal at egenix.com Fri Feb 18 22:35:35 2011 From: mal at egenix.com (M.-A. Lemburg) Date: Fri, 18 Feb 2011 22:35:35 +0100 Subject: [python-committers] do we still believe explicit relative imports are bad as PEP 8 claims? In-Reply-To: References: Message-ID: <4D5EE627.6040705@egenix.com> Brett Cannon wrote: > It says they are "highly discouraged" because "absolute imports are > more portable and usually more readable", but now that people have had > a chance to use explicit relative imports, do people still believe > this? I mean if we truly believed this then why did we add the syntax? > I know I have used it and love it, let alone that I don't buy the > portability argument. Let's put it this way: I think that PEP 8 gets way too much attention in Python land. It describes one way of doing things, but is not a bible or strict style guide (and even says that). Regarding relative imports: I think they were only added to be able to port code that uses Python2-style imports (which are relative as first try, then absolute) gradually to code that uses absolute imports. In all our larger projects we use absolute imports and this has often helped in organizing the code, finding definitions, etc. So far, we've not had any use for relative imports, but I can imagine some uses for e.g. plugin modules and component architectures that can be dropped into existing Python packages. Relative imports can also help porting code when doing package structure changes, e.g. moving top-level modules into a package. -- Marc-Andre Lemburg From jim at zope.com Fri Feb 18 23:14:49 2011 From: jim at zope.com (Jim Fulton) Date: Fri, 18 Feb 2011 17:14:49 -0500 Subject: [python-committers] do we still believe explicit relative imports are bad as PEP 8 claims? In-Reply-To: References: Message-ID: On Fri, Feb 18, 2011 at 3:36 PM, Brett Cannon wrote: > It says they are "highly discouraged" because "absolute imports are > more portable and usually more readable", but now that people have had > a chance to use explicit relative imports, do people still believe > this? I mean if we truly believed this then why did we add the syntax? > I know I have used it and love it, let alone that I don't buy the > portability argument. I've been living so long with versions of Python that didn't have explicit relative imports, I'd forgotten why I wanted them in in the first place. My initial reaction was that absolute imports are good enough, but that there are special cases where relative imports are needed and explicit relative imports address that need, so I'm sure we need the feature. Thinking about it more though, I *like* explicit relative imports because I think they can reduce the burden of reading the code. When you see: from . import foo You know that foo is local to (part of) this project. Of course, if you see: import thisproject.foo You know that foo is part of ``thisproject``, but you also have to remember that ``thisproject`` is *this* project. :) How useful this is can certainly be debated. I think I'd have to use the explicit relative import style in practice for a while before I was sure I liked it. I think I'll make a point of trying it out. Of course, the explicit relative import style makes moving packages around *somewhat* easier. I agree with Marc-Andre. We shouldn't worry too much about what PEP 8 says. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton From ziade.tarek at gmail.com Sat Feb 19 00:20:24 2011 From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=) Date: Sat, 19 Feb 2011 00:20:24 +0100 Subject: [python-committers] do we still believe explicit relative imports are bad as PEP 8 claims? In-Reply-To: <4D5EE627.6040705@egenix.com> References: <4D5EE627.6040705@egenix.com> Message-ID: On Fri, Feb 18, 2011 at 10:35 PM, M.-A. Lemburg wrote: > Brett Cannon wrote: >> It says they are "highly discouraged" because "absolute imports are >> more portable and usually more readable", but now that people have had >> a chance to use explicit relative imports, do people still believe >> this? I mean if we truly believed this then why did we add the syntax? >> I know I have used it and love it, let alone that I don't buy the >> portability argument. > > Let's put it this way: I think that PEP 8 gets way too much > attention in Python land. > > It describes one way of doing things, but is not a bible or > strict style guide (and even says that) Yeah but it exists. And it very useful to have, I'd say. 1 - when you start Python, it gives you a sense of how a "beautiful" Python code should look. 2 - for any new project, I personally recommend strict PEP 8 instead of inventing another convention. 3 - It's documented, widely adopted, and we have existing tools to check for compliancy out there. Cheers Tarek -- Tarek Ziad? | http://ziade.org From raymond.hettinger at gmail.com Sat Feb 19 02:30:27 2011 From: raymond.hettinger at gmail.com (Raymond Hettinger) Date: Fri, 18 Feb 2011 17:30:27 -0800 Subject: [python-committers] do we still believe explicit relative imports are bad as PEP 8 claims? In-Reply-To: References: Message-ID: <32370E2F-3933-4820-AEFF-3F4DBC716996@gmail.com> On Feb 18, 2011, at 12:36 PM, Brett Cannon wrote: > It says they are "highly discouraged" because "absolute imports are > more portable and usually more readable", but now that people have had > a chance to use explicit relative imports, do people still believe > this? I mean if we truly believed this then why did we add the syntax? > I know I have used it and love it, let alone that I don't buy the > portability argument. I still find relative imports to be a bit jarring and don't like the implied tight coupling of modules. The nest of relative imports in unittest is a good example of something that causes a mental hiccup when I read it and it seems like an anti-pattern. Raymond Lib/unittest/__init__.py ---------------------------- from .result import TestResult from .case import (TestCase, FunctionTestCase, SkipTest, skip, skipIf, skipUnless, expectedFailure) from .suite import BaseTestSuite, TestSuite from .loader import (TestLoader, defaultTestLoader, makeSuite, getTestCaseNames, findTestCases) from .main import TestProgram, main from .runner import TextTestRunner, TextTestResult from .signals import installHandler, registerResult, removeResult, removeHandler From ncoghlan at gmail.com Sat Feb 19 09:51:48 2011 From: ncoghlan at gmail.com (Nick Coghlan) Date: Sat, 19 Feb 2011 18:51:48 +1000 Subject: [python-committers] do we still believe explicit relative imports are bad as PEP 8 claims? In-Reply-To: <32370E2F-3933-4820-AEFF-3F4DBC716996@gmail.com> References: <32370E2F-3933-4820-AEFF-3F4DBC716996@gmail.com> Message-ID: On Sat, Feb 19, 2011 at 11:30 AM, Raymond Hettinger wrote: > > On Feb 18, 2011, at 12:36 PM, Brett Cannon wrote: > >> It says they are "highly discouraged" because "absolute imports are >> more portable and usually more readable", but now that people have had >> a chance to use explicit relative imports, do people still believe >> this? I mean if we truly believed this then why did we add the syntax? >> I know I have used it and love it, let alone that I don't buy the >> portability argument. > > I still find relative imports to be a bit jarring and don't like the > implied tight coupling of modules. ? The nest of relative imports > in unittest is a good example of something that causes a mental > hiccup when I read it and it seems like an anti-pattern. The particular pattern employed by unittest would be a pseudo-module (i.e. a package that tries to present itself as really just a module) rather than explicit relative imports in general, though. I'm personally fine with PEP 8 continuing to advocate absolute imports. Explicit relative imports make certain kinds of code easier to write, but they shouldn't be the default choice for a new project. Cheers, Nick. -- Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia From g.brandl at gmx.net Sun Feb 20 11:12:33 2011 From: g.brandl at gmx.net (Georg Brandl) Date: Sun, 20 Feb 2011 10:12:33 +0000 Subject: [python-committers] releasing 3.2 final Message-ID: I'm now starting the release process. You can find me in #python-dev if there is something I need to be aware of. cheers, Georg From georg at python.org Sun Feb 20 23:22:47 2011 From: georg at python.org (Georg Brandl) Date: Sun, 20 Feb 2011 23:22:47 +0100 Subject: [python-committers] [RELEASED] Python 3.2 Message-ID: <4D619437.7050507@python.org> On behalf of the Python development team, I'm delighted to announce Python 3.2 final release. Python 3.2 is a continuation of the efforts to improve and stabilize the Python 3.x line. Since the final release of Python 2.7, the 2.x line will only receive bugfixes, and new features are developed for 3.x only. Since PEP 3003, the Moratorium on Language Changes, is in effect, there are no changes in Python's syntax and built-in types in Python 3.2. Development efforts concentrated on the standard library and support for porting code to Python 3. Highlights are: * numerous improvements to the unittest module * PEP 3147, support for .pyc repository directories * PEP 3149, support for version tagged dynamic libraries * PEP 3148, a new futures library for concurrent programming * PEP 384, a stable ABI for extension modules * PEP 391, dictionary-based logging configuration * an overhauled GIL implementation that reduces contention * an extended email package that handles bytes messages * a much improved ssl module with support for SSL contexts and certificate hostname matching * a sysconfig module to access configuration information * additions to the shutil module, among them archive file support * many enhancements to configparser, among them mapping protocol support * improvements to pdb, the Python debugger * countless fixes regarding bytes/string issues; among them full support for a bytes environment (filenames, environment variables) * many consistency and behavior fixes for numeric operations For a more extensive list of changes in 3.2, see http://docs.python.org/3.2/whatsnew/3.2.html To download Python 3.2 visit: http://www.python.org/download/releases/3.2/ Please consider trying Python 3.2 with your code and reporting any bugs you may notice to: http://bugs.python.org/ Enjoy! - -- Georg Brandl, Release Manager georg at python.org (on behalf of the entire python-dev team and 3.2's contributors) From g.brandl at gmx.net Mon Feb 21 19:11:52 2011 From: g.brandl at gmx.net (Georg Brandl) Date: Mon, 21 Feb 2011 19:11:52 +0100 Subject: [python-committers] branches are open Message-ID: py3k is now 3.3a0, and I've created a new release32-maint branch. Thanks to Martin for setting up svnmerge on the new branch; please merge all bug fixes to release32-maint as usual. Benjamin, how long will you want to maintain 3.1 in bugfix mode? Georg From g.brandl at gmx.net Mon Feb 21 19:14:45 2011 From: g.brandl at gmx.net (Georg Brandl) Date: Mon, 21 Feb 2011 19:14:45 +0100 Subject: [python-committers] branches are open In-Reply-To: References: Message-ID: On 21.02.2011 19:11, Georg Brandl wrote: > py3k is now 3.3a0, and I've created a new release32-maint branch. > Thanks to Martin for setting up svnmerge on the new branch; please > merge all bug fixes to release32-maint as usual. One more thing: I've added a 3.2regression keyword to the bug tracker. Please flag such regressions with this keyword when you do triage, so that I can better assess the best timescale for the 3.2.1 release. Thanks, Georg From tjreedy at udel.edu Mon Feb 21 19:25:01 2011 From: tjreedy at udel.edu (Terry Reedy) Date: Mon, 21 Feb 2011 13:25:01 -0500 Subject: [python-committers] branches are open In-Reply-To: References: Message-ID: <4D62ADFD.1050502@udel.edu> On 2/21/2011 1:11 PM, Georg Brandl wrote: > py3k is now 3.3a0, Should that be 3.3.0a0, or does adding .0 come later? From g.brandl at gmx.net Mon Feb 21 21:05:03 2011 From: g.brandl at gmx.net (Georg Brandl) Date: Mon, 21 Feb 2011 21:05:03 +0100 Subject: [python-committers] branches are open In-Reply-To: <4D62ADFD.1050502@udel.edu> References: <4D62ADFD.1050502@udel.edu> Message-ID: On 21.02.2011 19:25, Terry Reedy wrote: > > > On 2/21/2011 1:11 PM, Georg Brandl wrote: >> py3k is now 3.3a0, > > Should that be 3.3.0a0, or does adding .0 come later? I'll leave that to the release manager :) Georg From benjamin at python.org Wed Feb 23 04:11:58 2011 From: benjamin at python.org (Benjamin Peterson) Date: Tue, 22 Feb 2011 21:11:58 -0600 Subject: [python-committers] branches are open In-Reply-To: References: Message-ID: 2011/2/21 Georg Brandl : > py3k is now 3.3a0, and I've created a new release32-maint branch. > Thanks to Martin for setting up svnmerge on the new branch; please > merge all bug fixes to release32-maint as usual. > > Benjamin, how long will you want to maintain 3.1 in bugfix mode? I will try to release sometime this spring as soon as I have time. Don't feel obliged to backport everything. -- Regards, Benjamin From barry at python.org Thu Feb 24 00:13:30 2011 From: barry at python.org (Barry Warsaw) Date: Wed, 23 Feb 2011 18:13:30 -0500 Subject: [python-committers] do we still believe explicit relative imports are bad as PEP 8 claims? In-Reply-To: References: Message-ID: <20110223181330.0525f2e3@python.org> On Feb 18, 2011, at 12:36 PM, Brett Cannon wrote: >It says they are "highly discouraged" because "absolute imports are >more portable and usually more readable", but now that people have had >a chance to use explicit relative imports, do people still believe >this? I mean if we truly believed this then why did we add the syntax? >I know I have used it and love it, let alone that I don't buy the >portability argument. I agree with others that explicit relative imports should still be discouraged. I've run into problems with them where imports break under some situations. I don't remember the details, but I think it was when running unittests or under -m or something. Yeah, I should file a bug next time I run into it. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From brett at python.org Thu Feb 24 00:32:41 2011 From: brett at python.org (Brett Cannon) Date: Wed, 23 Feb 2011 15:32:41 -0800 Subject: [python-committers] do we still believe explicit relative imports are bad as PEP 8 claims? In-Reply-To: <20110223181330.0525f2e3@python.org> References: <20110223181330.0525f2e3@python.org> Message-ID: On Wed, Feb 23, 2011 at 15:13, Barry Warsaw wrote: > On Feb 18, 2011, at 12:36 PM, Brett Cannon wrote: > > >It says they are "highly discouraged" because "absolute imports are > >more portable and usually more readable", but now that people have had > >a chance to use explicit relative imports, do people still believe > >this? I mean if we truly believed this then why did we add the syntax? > >I know I have used it and love it, let alone that I don't buy the > >portability argument. > > I agree with others that explicit relative imports should still be > discouraged. I've run into problems with them where imports break under > some > situations. I don't remember the details, but I think it was when running > unittests or under -m or something. Yeah, I should file a bug next time I > run > into it. What kind of example are you setting as the FLUFL if you won't even file a bug report?!? Don't make me hold your __future__ statement ransom! -------------- next part -------------- An HTML attachment was scrubbed... URL: From brett at python.org Thu Feb 24 02:53:52 2011 From: brett at python.org (Brett Cannon) Date: Wed, 23 Feb 2011 17:53:52 -0800 Subject: [python-committers] www.python.org/3.2.(x|0) do not exist Message-ID: Not sure if Martin is the only person who can fix this, but it would be nice to have those URLs working. -------------- next part -------------- An HTML attachment was scrubbed... URL: From barry at python.org Thu Feb 24 02:58:32 2011 From: barry at python.org (Barry Warsaw) Date: Wed, 23 Feb 2011 20:58:32 -0500 Subject: [python-committers] do we still believe explicit relative imports are bad as PEP 8 claims? In-Reply-To: References: <20110223181330.0525f2e3@python.org> Message-ID: <20110223205832.26bd1a89@python.org> On Feb 23, 2011, at 03:32 PM, Brett Cannon wrote: >What kind of example are you setting as the FLUFL if you won't even file a >bug report?!? Don't make me hold your __future__ statement ransom! If I filed a bug report every time I actually found a bug, I'd never be able to read email! Wait, hmmm... -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From martin at v.loewis.de Thu Feb 24 07:50:26 2011 From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=) Date: Thu, 24 Feb 2011 07:50:26 +0100 Subject: [python-committers] http://www.python.org/3.2.(x|0) do not exist In-Reply-To: References: Message-ID: <4D65FFB2.9080303@v.loewis.de> Am 24.02.2011 02:39, schrieb Brett Cannon: > Not sure if Martin is the only person who can fix this, but it would be > nice to have those URLs working. I have added a redirect for 3.2.x. I haven't added one for 3.2.0, since we currently don't have any redirects for X.Y.0, only for X.Y. Regards, Martin From ncoghlan at gmail.com Thu Feb 24 13:39:01 2011 From: ncoghlan at gmail.com (Nick Coghlan) Date: Thu, 24 Feb 2011 22:39:01 +1000 Subject: [python-committers] do we still believe explicit relative imports are bad as PEP 8 claims? In-Reply-To: <20110223181330.0525f2e3@python.org> References: <20110223181330.0525f2e3@python.org> Message-ID: On Thu, Feb 24, 2011 at 9:13 AM, Barry Warsaw wrote: > On Feb 18, 2011, at 12:36 PM, Brett Cannon wrote: > >>It says they are "highly discouraged" because "absolute imports are >>more portable and usually more readable", but now that people have had >>a chance to use explicit relative imports, do people still believe >>this? I mean if we truly believed this then why did we add the syntax? >>I know I have used it and love it, let alone that I don't buy the >>portability argument. > > I agree with others that explicit relative imports should still be > discouraged. ?I've run into problems with them where imports break under some > situations. ?I don't remember the details, but I think it was when running > unittests or under -m or something. ?Yeah, I should file a bug next time I run > into it. /me points to PEP 366 Relative imports and __main__ modules inside packages did *not* play nicely with each other at all for a while there.However, as far as I am aware, the only time you get in trouble now is when you run scripts inside packages directly (rather than via -m), but that causes trouble for multiple reasons, not just broken relative imports. If there are other cases that still have issues, I'd definitely like to hear about them. Cheers, Nick. -- Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia From brian.curtin at gmail.com Thu Feb 24 19:20:58 2011 From: brian.curtin at gmail.com (Brian Curtin) Date: Thu, 24 Feb 2011 12:20:58 -0600 Subject: [python-committers] Quick survey for PyCon talk on core development Message-ID: Hi all, If you have a few free minutes, would you mind filling out a couple of questions? I'm giving a talk at PyCon about core development [0] and wanted to sprinkle in some info about the people doing the work. https://spreadsheets.google.com/viewform?formkey=dEZXWVhQMnBGREU0TUl0TTRTWk1zOEE6MQ Feel free to answer or skip any questions. Your name isn't associated with it. Thanks a lot for your time, and I look forward to seeing any of you at PyCon! Brian [0] http://us.pycon.org/2011/schedule/presentations/7/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From brett at python.org Thu Feb 24 19:47:51 2011 From: brett at python.org (Brett Cannon) Date: Thu, 24 Feb 2011 10:47:51 -0800 Subject: [python-committers] Quick survey for PyCon talk on core development In-Reply-To: References: Message-ID: Just so people know, I took the survey and it actually only take a couple of minutes, not even a few. On Thu, Feb 24, 2011 at 10:20, Brian Curtin wrote: > Hi all, > > If you have a few free minutes, would you mind filling out a couple of > questions? I'm giving a talk at PyCon about core development [0] and wanted > to sprinkle in some info about the people doing the work. > > > https://spreadsheets.google.com/viewform?formkey=dEZXWVhQMnBGREU0TUl0TTRTWk1zOEE6MQ > > Feel free to answer or skip any questions. Your name isn't associated with > it. > > Thanks a lot for your time, and I look forward to seeing any of you at > PyCon! > > Brian > > > [0] http://us.pycon.org/2011/schedule/presentations/7/ > > _______________________________________________ > python-committers mailing list > python-committers at python.org > http://mail.python.org/mailman/listinfo/python-committers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lukasz at langa.pl Thu Feb 24 20:15:44 2011 From: lukasz at langa.pl (=?utf-8?Q?=C5=81ukasz_Langa?=) Date: Thu, 24 Feb 2011 20:15:44 +0100 Subject: [python-committers] Quick survey for PyCon talk on core development In-Reply-To: References: Message-ID: Wiadomo?? napisana przez Brett Cannon w dniu 2011-02-24, o godz. 19:47: > Just so people know, I took the survey and it actually only take a couple of minutes, not even a few. > Exactly, and it's fun. Brian, you might consider tweeting about it. Then again, you might get some false positives ;-) -- Best regards, ?ukasz Langa tel. +48 791 080 144 WWW http://lukasz.langa.pl/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From guido at python.org Thu Feb 24 20:58:00 2011 From: guido at python.org (Guido van Rossum) Date: Thu, 24 Feb 2011 11:58:00 -0800 Subject: [python-committers] Quick survey for PyCon talk on core development In-Reply-To: References: Message-ID: Actually you should post it to the python-dev IRC group. 2011/2/24 ?ukasz Langa : > Wiadomo?? napisana przez Brett Cannon w dniu 2011-02-24, o godz. 19:47: > > Just so people know, I took the survey and it actually only take a couple of > minutes, not even a few. > > > Exactly, and it's fun. > Brian, you might consider tweeting about it. Then again, you might get some > false positives ;-) > -- > Best regards, > ?ukasz Langa > tel. +48 791 080 144 > WWW http://lukasz.langa.pl/ > > _______________________________________________ > python-committers mailing list > python-committers at python.org > http://mail.python.org/mailman/listinfo/python-committers > > -- --Guido van Rossum (python.org/~guido)