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: <E7CDB684-105A-4783-B5D4-86D2E89E0701@holdenweb.com>

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: <E7CDB684-105A-4783-B5D4-86D2E89E0701@holdenweb.com>
References: <E7CDB684-105A-4783-B5D4-86D2E89E0701@holdenweb.com>
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: <E7CDB684-105A-4783-B5D4-86D2E89E0701@holdenweb.com>
	<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: <E7CDB684-105A-4783-B5D4-86D2E89E0701@holdenweb.com>
	<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: <http://mail.python.org/pipermail/python-committers/attachments/20110202/bbbb0c1e/attachment.pgp>

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: <E7CDB684-105A-4783-B5D4-86D2E89E0701@holdenweb.com>	<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: <E7CDB684-105A-4783-B5D4-86D2E89E0701@holdenweb.com>
	<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: <E7CDB684-105A-4783-B5D4-86D2E89E0701@holdenweb.com>	<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: <E7CDB684-105A-4783-B5D4-86D2E89E0701@holdenweb.com>
	<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: <E7CDB684-105A-4783-B5D4-86D2E89E0701@holdenweb.com>	<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: <E7CDB684-105A-4783-B5D4-86D2E89E0701@holdenweb.com>
	<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: <E7CDB684-105A-4783-B5D4-86D2E89E0701@holdenweb.com>
	<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: <AD12F48E-65D5-4B54-89DB-1EA14301A9C9@holdenweb.com>


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: <AD12F48E-65D5-4B54-89DB-1EA14301A9C9@holdenweb.com>
References: <E7CDB684-105A-4783-B5D4-86D2E89E0701@holdenweb.com>
	<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>
	<AD12F48E-65D5-4B54-89DB-1EA14301A9C9@holdenweb.com>
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: <E7CDB684-105A-4783-B5D4-86D2E89E0701@holdenweb.com>	<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: <E7CDB684-105A-4783-B5D4-86D2E89E0701@holdenweb.com>
	<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: <http://mail.python.org/pipermail/python-committers/attachments/20110202/c8b7cab6/attachment.pgp>

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: <E7CDB684-105A-4783-B5D4-86D2E89E0701@holdenweb.com>
	<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: <AANLkTikYpdtvn1aePt+PAfZaqtfEer+pSJVP2JEABncL@mail.gmail.com>

On Thu, Feb 3, 2011 at 6:30 AM, Barry Warsaw <barry at python.org> 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: <AANLkTikYpdtvn1aePt+PAfZaqtfEer+pSJVP2JEABncL@mail.gmail.com>
References: <E7CDB684-105A-4783-B5D4-86D2E89E0701@holdenweb.com>
	<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>
	<AANLkTikYpdtvn1aePt+PAfZaqtfEer+pSJVP2JEABncL@mail.gmail.com>
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: <http://mail.python.org/pipermail/python-committers/attachments/20110202/4ed09f2c/attachment.pgp>

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: <E7CDB684-105A-4783-B5D4-86D2E89E0701@holdenweb.com>	<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>	<AANLkTikYpdtvn1aePt+PAfZaqtfEer+pSJVP2JEABncL@mail.gmail.com>
	<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: <E7CDB684-105A-4783-B5D4-86D2E89E0701@holdenweb.com>
	<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>
	<AANLkTikYpdtvn1aePt+PAfZaqtfEer+pSJVP2JEABncL@mail.gmail.com>
	<20110202181612.11d54e3a@python.org>
Message-ID: <AANLkTikJbAkJiyV=-VVfGUd1wnrp1c2j-fc4GcF8054G@mail.gmail.com>

On Thu, Feb 3, 2011 at 9:16 AM, Barry Warsaw <barry at python.org> 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: <AANLkTikJbAkJiyV=-VVfGUd1wnrp1c2j-fc4GcF8054G@mail.gmail.com>
References: <E7CDB684-105A-4783-B5D4-86D2E89E0701@holdenweb.com>
	<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>
	<AANLkTikYpdtvn1aePt+PAfZaqtfEer+pSJVP2JEABncL@mail.gmail.com>
	<20110202181612.11d54e3a@python.org>
	<AANLkTikJbAkJiyV=-VVfGUd1wnrp1c2j-fc4GcF8054G@mail.gmail.com>
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 <barry at python.org> 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: <E7CDB684-105A-4783-B5D4-86D2E89E0701@holdenweb.com>
	<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>
	<AANLkTikYpdtvn1aePt+PAfZaqtfEer+pSJVP2JEABncL@mail.gmail.com>
	<20110202181612.11d54e3a@python.org>
	<AANLkTikJbAkJiyV=-VVfGUd1wnrp1c2j-fc4GcF8054G@mail.gmail.com>
	<1FD2B821-02AA-430D-BD20-88AD6C40B926@holdenweb.com>
Message-ID: <AANLkTik9XOX8eEAL-CoRTYD4ZSDsZTWqEgnReQE=_KU+@mail.gmail.com>

On Thu, Feb 3, 2011 at 9:35 AM, Steve Holden <steve at holdenweb.com> 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: <AANLkTik9XOX8eEAL-CoRTYD4ZSDsZTWqEgnReQE=_KU+@mail.gmail.com>
References: <E7CDB684-105A-4783-B5D4-86D2E89E0701@holdenweb.com>
	<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>
	<AANLkTikYpdtvn1aePt+PAfZaqtfEer+pSJVP2JEABncL@mail.gmail.com>
	<20110202181612.11d54e3a@python.org>
	<AANLkTikJbAkJiyV=-VVfGUd1wnrp1c2j-fc4GcF8054G@mail.gmail.com>
	<1FD2B821-02AA-430D-BD20-88AD6C40B926@holdenweb.com>
	<AANLkTik9XOX8eEAL-CoRTYD4ZSDsZTWqEgnReQE=_KU+@mail.gmail.com>
Message-ID: <AANLkTikaj9qvk=DQSZ7nHAJp9sRTQvzJPk7qRxawDLHm@mail.gmail.com>

(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: <E7CDB684-105A-4783-B5D4-86D2E89E0701@holdenweb.com>	<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>	<AANLkTikYpdtvn1aePt+PAfZaqtfEer+pSJVP2JEABncL@mail.gmail.com>	<20110202181612.11d54e3a@python.org>	<AANLkTikJbAkJiyV=-VVfGUd1wnrp1c2j-fc4GcF8054G@mail.gmail.com>
	<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<barry at python.org>  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: <E7CDB684-105A-4783-B5D4-86D2E89E0701@holdenweb.com>	<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: <E7CDB684-105A-4783-B5D4-86D2E89E0701@holdenweb.com>
	<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>
	<AANLkTikYpdtvn1aePt+PAfZaqtfEer+pSJVP2JEABncL@mail.gmail.com>
	<20110202181612.11d54e3a@python.org>
	<AANLkTikJbAkJiyV=-VVfGUd1wnrp1c2j-fc4GcF8054G@mail.gmail.com>
	<1FD2B821-02AA-430D-BD20-88AD6C40B926@holdenweb.com>
	<4D49F52D.7070705@python.org>
Message-ID: <AANLkTinPvF7kkQ5=jGGqftFH=0bbknwQGs7_qYtyLkOx@mail.gmail.com>

On Wed, Feb 2, 2011 at 7:22 PM, Michael Foord <mfoord at python.org> 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<barry at python.org> ?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: <E7CDB684-105A-4783-B5D4-86D2E89E0701@holdenweb.com>	<4D495CBA.6040706@python.org>
	<20110202114702.133c59de@python.org>
Message-ID: <iidn6o$ctg$1@dough.gmane.org>

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: <E7CDB684-105A-4783-B5D4-86D2E89E0701@holdenweb.com>	<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: <iidnc5$ctg$2@dough.gmane.org>

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: <E7CDB684-105A-4783-B5D4-86D2E89E0701@holdenweb.com>	<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: <iidnkt$g14$1@dough.gmane.org>

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: <E7CDB684-105A-4783-B5D4-86D2E89E0701@holdenweb.com>
	<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: <AANLkTi=Rn7e8=tV+cN9Gj=LJgEgBPsHqxO2d30EP5gwg@mail.gmail.com>

On Thu, Feb 3, 2011 at 10:37 AM, Jesus Cea <jcea at jcea.es> 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: <AANLkTi=Rn7e8=tV+cN9Gj=LJgEgBPsHqxO2d30EP5gwg@mail.gmail.com>
References: <E7CDB684-105A-4783-B5D4-86D2E89E0701@holdenweb.com>
	<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>
	<AANLkTi=Rn7e8=tV+cN9Gj=LJgEgBPsHqxO2d30EP5gwg@mail.gmail.com>
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 <jcea at jcea.es> 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: <E7CDB684-105A-4783-B5D4-86D2E89E0701@holdenweb.com>
	<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>
	<AANLkTi=Rn7e8=tV+cN9Gj=LJgEgBPsHqxO2d30EP5gwg@mail.gmail.com>
	<1296735633.3705.3.camel@localhost.localdomain>
Message-ID: <AANLkTimrR4M7H-PZ50fcc0DQk7zuq70YvyMFs9FEJRbP@mail.gmail.com>

On Thu, Feb 3, 2011 at 10:20 PM, Antoine Pitrou <solipsis at pitrou.net> 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 <jcea at jcea.es> 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: <iidnc5$ctg$2@dough.gmane.org>
References: <E7CDB684-105A-4783-B5D4-86D2E89E0701@holdenweb.com>
	<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>
	<iidnc5$ctg$2@dough.gmane.org>
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: <http://mail.python.org/pipermail/python-committers/attachments/20110203/7abfc2af/attachment.pgp>

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: <iidn6o$ctg$1@dough.gmane.org>
References: <E7CDB684-105A-4783-B5D4-86D2E89E0701@holdenweb.com>
	<4D495CBA.6040706@python.org> <20110202114702.133c59de@python.org>
	<iidn6o$ctg$1@dough.gmane.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: <http://mail.python.org/pipermail/python-committers/attachments/20110203/c0254e4f/attachment-0001.pgp>

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: <iidnc5$ctg$2@dough.gmane.org>
References: <E7CDB684-105A-4783-B5D4-86D2E89E0701@holdenweb.com>
	<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>
	<iidnc5$ctg$2@dough.gmane.org>
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: <E7CDB684-105A-4783-B5D4-86D2E89E0701@holdenweb.com>
	<4D495CBA.6040706@python.org> <20110202114702.133c59de@python.org>
	<iidn6o$ctg$1@dough.gmane.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: <E7CDB684-105A-4783-B5D4-86D2E89E0701@holdenweb.com>	<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>	<iidnc5$ctg$2@dough.gmane.org>
	<1296769153.3925.22.camel@localhost.localdomain>
Message-ID: <iif7t6$2it$1@dough.gmane.org>

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: <E7CDB684-105A-4783-B5D4-86D2E89E0701@holdenweb.com>	<4D495CBA.6040706@python.org>
	<20110202114702.133c59de@python.org>	<iidn6o$ctg$1@dough.gmane.org>
	<20110203163658.479d1073@python.org>
Message-ID: <iif86j$2it$2@dough.gmane.org>

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...

<wink>
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: <E7CDB684-105A-4783-B5D4-86D2E89E0701@holdenweb.com>
	<4D495CBA.6040706@python.org> <20110202114702.133c59de@python.org>
	<iidn6o$ctg$1@dough.gmane.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: <http://mail.python.org/pipermail/python-committers/attachments/20110203/f3b0a519/attachment.pgp>

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: <iif86j$2it$2@dough.gmane.org>
References: <E7CDB684-105A-4783-B5D4-86D2E89E0701@holdenweb.com>
	<4D495CBA.6040706@python.org> <20110202114702.133c59de@python.org>
	<iidn6o$ctg$1@dough.gmane.org> <20110203163658.479d1073@python.org>
	<iif86j$2it$2@dough.gmane.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: <http://mail.python.org/pipermail/python-committers/attachments/20110203/ba633dbc/attachment-0001.pgp>

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: <AANLkTi=Rn7e8=tV+cN9Gj=LJgEgBPsHqxO2d30EP5gwg@mail.gmail.com>
References: <E7CDB684-105A-4783-B5D4-86D2E89E0701@holdenweb.com>	<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>
	<AANLkTi=Rn7e8=tV+cN9Gj=LJgEgBPsHqxO2d30EP5gwg@mail.gmail.com>
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 <jcea at jcea.es> 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: <AANLkTimrR4M7H-PZ50fcc0DQk7zuq70YvyMFs9FEJRbP@mail.gmail.com>
References: <E7CDB684-105A-4783-B5D4-86D2E89E0701@holdenweb.com>	<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>	<AANLkTi=Rn7e8=tV+cN9Gj=LJgEgBPsHqxO2d30EP5gwg@mail.gmail.com>	<1296735633.3705.3.camel@localhost.localdomain>
	<AANLkTimrR4M7H-PZ50fcc0DQk7zuq70YvyMFs9FEJRbP@mail.gmail.com>
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: <E7CDB684-105A-4783-B5D4-86D2E89E0701@holdenweb.com>
	<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>
	<AANLkTi=Rn7e8=tV+cN9Gj=LJgEgBPsHqxO2d30EP5gwg@mail.gmail.com>
	<1296735633.3705.3.camel@localhost.localdomain>
	<AANLkTimrR4M7H-PZ50fcc0DQk7zuq70YvyMFs9FEJRbP@mail.gmail.com>
	<4D4B6FE2.8000808@jcea.es>
Message-ID: <AANLkTi=hoc1=UGsJViWO3kHymV5zhqVt4rqL3=j54mPZ@mail.gmail.com>

On Fri, Feb 4, 2011 at 1:17 PM, Jesus Cea <jcea at jcea.es> 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: <E7CDB684-105A-4783-B5D4-86D2E89E0701@holdenweb.com>	<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>	<AANLkTi=Rn7e8=tV+cN9Gj=LJgEgBPsHqxO2d30EP5gwg@mail.gmail.com>
	<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 <jcea at jcea.es> 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: <AANLkTi=hoc1=UGsJViWO3kHymV5zhqVt4rqL3=j54mPZ@mail.gmail.com>
References: <E7CDB684-105A-4783-B5D4-86D2E89E0701@holdenweb.com>	<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>	<AANLkTi=Rn7e8=tV+cN9Gj=LJgEgBPsHqxO2d30EP5gwg@mail.gmail.com>	<1296735633.3705.3.camel@localhost.localdomain>	<AANLkTimrR4M7H-PZ50fcc0DQk7zuq70YvyMFs9FEJRbP@mail.gmail.com>	<4D4B6FE2.8000808@jcea.es>
	<AANLkTi=hoc1=UGsJViWO3kHymV5zhqVt4rqL3=j54mPZ@mail.gmail.com>
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 <jcea at jcea.es> 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: <E7CDB684-105A-4783-B5D4-86D2E89E0701@holdenweb.com>
	<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: <E7CDB684-105A-4783-B5D4-86D2E89E0701@holdenweb.com>	<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>	<AANLkTi=Rn7e8=tV+cN9Gj=LJgEgBPsHqxO2d30EP5gwg@mail.gmail.com>	<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: <E7CDB684-105A-4783-B5D4-86D2E89E0701@holdenweb.com>
	<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>
	<AANLkTi=Rn7e8=tV+cN9Gj=LJgEgBPsHqxO2d30EP5gwg@mail.gmail.com>
	<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: <E7CDB684-105A-4783-B5D4-86D2E89E0701@holdenweb.com>	<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>	<AANLkTi=Rn7e8=tV+cN9Gj=LJgEgBPsHqxO2d30EP5gwg@mail.gmail.com>	<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: <AANLkTi=MnReyridDcwEaEMVY=c=0PitgU+u8che9ngsc@mail.gmail.com>

On Fri, Feb 4, 2011 at 1:50 PM, Jesus Cea <jcea at jcea.es> 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: <AANLkTi=MnReyridDcwEaEMVY=c=0PitgU+u8che9ngsc@mail.gmail.com>
References: <1296820351.742.27.camel@marge>
	<4D4BEC34.8080902@jcea.es>	<1296821742.1739.3.camel@marge>
	<4D4BF618.2070100@jcea.es>
	<AANLkTi=MnReyridDcwEaEMVY=c=0PitgU+u8che9ngsc@mail.gmail.com>
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>
	<AANLkTi=MnReyridDcwEaEMVY=c=0PitgU+u8che9ngsc@mail.gmail.com>
	<4D4C03C9.5070308@jcea.es>
Message-ID: <AANLkTimDOM3zQoePE+Y4qKftfa6dLwjGx=G=OpzOZ2nb@mail.gmail.com>

On Fri, Feb 4, 2011 at 2:48 PM, Jesus Cea <jcea at jcea.es> 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>
	<AANLkTi=MnReyridDcwEaEMVY=c=0PitgU+u8che9ngsc@mail.gmail.com>
	<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: <E7CDB684-105A-4783-B5D4-86D2E89E0701@holdenweb.com>
	<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>
	<AANLkTi=Rn7e8=tV+cN9Gj=LJgEgBPsHqxO2d30EP5gwg@mail.gmail.com>
	<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 <solipsis at pitrou.net> 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: <AANLkTi=MnReyridDcwEaEMVY=c=0PitgU+u8che9ngsc@mail.gmail.com>
References: <1296820351.742.27.camel@marge> <4D4BEC34.8080902@jcea.es>
	<1296821742.1739.3.camel@marge> <4D4BF618.2070100@jcea.es>
	<AANLkTi=MnReyridDcwEaEMVY=c=0PitgU+u8che9ngsc@mail.gmail.com>
Message-ID: <AANLkTikTowuCeCuYU1-W0dMxMROaCTYuyuSXgioTPYBs@mail.gmail.com>

On Fri, Feb 4, 2011 at 14:31, Tarek Ziad? <ziade.tarek at gmail.com> 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: <AANLkTikTowuCeCuYU1-W0dMxMROaCTYuyuSXgioTPYBs@mail.gmail.com>
References: <1296820351.742.27.camel@marge> <4D4BEC34.8080902@jcea.es>
	<1296821742.1739.3.camel@marge> <4D4BF618.2070100@jcea.es>
	<AANLkTi=MnReyridDcwEaEMVY=c=0PitgU+u8che9ngsc@mail.gmail.com>
	<AANLkTikTowuCeCuYU1-W0dMxMROaCTYuyuSXgioTPYBs@mail.gmail.com>
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: <AANLkTimDOM3zQoePE+Y4qKftfa6dLwjGx=G=OpzOZ2nb@mail.gmail.com>
References: <1296820351.742.27.camel@marge>
	<4D4BEC34.8080902@jcea.es>	<1296821742.1739.3.camel@marge>
	<4D4BF618.2070100@jcea.es>	<AANLkTi=MnReyridDcwEaEMVY=c=0PitgU+u8che9ngsc@mail.gmail.com>	<4D4C03C9.5070308@jcea.es>
	<AANLkTimDOM3zQoePE+Y4qKftfa6dLwjGx=G=OpzOZ2nb@mail.gmail.com>
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: <E7CDB684-105A-4783-B5D4-86D2E89E0701@holdenweb.com>
	<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>
	<AANLkTi=Rn7e8=tV+cN9Gj=LJgEgBPsHqxO2d30EP5gwg@mail.gmail.com>
	<4D4B6E28.4010209@jcea.es>
	<1296822354.3774.3.camel@localhost.localdomain>
	<20110204143019.5B3DB241BF5@kimball.webabinitio.net>
Message-ID: <AANLkTi=YZWdf-OMK64=Gh1uKur2CGPvac7GD0ouOq+-r@mail.gmail.com>

On Sat, Feb 5, 2011 at 12:30 AM, R. David Murray <rdmurray at bitdance.com> 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: <AANLkTimDOM3zQoePE+Y4qKftfa6dLwjGx=G=OpzOZ2nb@mail.gmail.com>
References: <1296820351.742.27.camel@marge> <4D4BEC34.8080902@jcea.es>
	<1296821742.1739.3.camel@marge> <4D4BF618.2070100@jcea.es>
	<AANLkTi=MnReyridDcwEaEMVY=c=0PitgU+u8che9ngsc@mail.gmail.com>
	<4D4C03C9.5070308@jcea.es>
	<AANLkTimDOM3zQoePE+Y4qKftfa6dLwjGx=G=OpzOZ2nb@mail.gmail.com>
Message-ID: <AANLkTimW9YObSvAubt_XJ4vuxqLNdytENp8rGYx5Rzjo@mail.gmail.com>

On Fri, Feb 4, 2011 at 11:57 PM, Tarek Ziad? <ziade.tarek at gmail.com> 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>
	<AANLkTi=MnReyridDcwEaEMVY=c=0PitgU+u8che9ngsc@mail.gmail.com>
	<4D4C03C9.5070308@jcea.es>
	<AANLkTimDOM3zQoePE+Y4qKftfa6dLwjGx=G=OpzOZ2nb@mail.gmail.com>
	<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: <http://mail.python.org/pipermail/python-committers/attachments/20110204/a1fdb1c2/attachment.pgp>

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: <E7CDB684-105A-4783-B5D4-86D2E89E0701@holdenweb.com>
	<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>
	<AANLkTi=Rn7e8=tV+cN9Gj=LJgEgBPsHqxO2d30EP5gwg@mail.gmail.com>
	<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: <http://mail.python.org/pipermail/python-committers/attachments/20110204/14057898/attachment.pgp>

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: <E7CDB684-105A-4783-B5D4-86D2E89E0701@holdenweb.com>	<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>	<AANLkTi=Rn7e8=tV+cN9Gj=LJgEgBPsHqxO2d30EP5gwg@mail.gmail.com>	<4D4B6E28.4010209@jcea.es>
	<20110204110325.4e172d3c@python.org>
Message-ID: <iih8nd$kgn$1@dough.gmane.org>

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: <E7CDB684-105A-4783-B5D4-86D2E89E0701@holdenweb.com>
	<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: <http://mail.python.org/pipermail/python-committers/attachments/20110204/45782eb5/attachment.pgp>

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: <AANLkTi=YZWdf-OMK64=Gh1uKur2CGPvac7GD0ouOq+-r@mail.gmail.com>
References: <E7CDB684-105A-4783-B5D4-86D2E89E0701@holdenweb.com>
	<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>
	<AANLkTi=Rn7e8=tV+cN9Gj=LJgEgBPsHqxO2d30EP5gwg@mail.gmail.com>
	<4D4B6E28.4010209@jcea.es>
	<1296822354.3774.3.camel@localhost.localdomain>
	<20110204143019.5B3DB241BF5@kimball.webabinitio.net>
	<AANLkTi=YZWdf-OMK64=Gh1uKur2CGPvac7GD0ouOq+-r@mail.gmail.com>
Message-ID: <AANLkTim0CmO33LXZhD_2F94=21WO8kv2=zBqSmN2FJXw@mail.gmail.com>

On Fri, Feb 4, 2011 at 16:49, Nick Coghlan <ncoghlan at gmail.com> 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
<branch> 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: <AANLkTim0CmO33LXZhD_2F94=21WO8kv2=zBqSmN2FJXw@mail.gmail.com>
References: <E7CDB684-105A-4783-B5D4-86D2E89E0701@holdenweb.com>
	<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>
	<AANLkTi=Rn7e8=tV+cN9Gj=LJgEgBPsHqxO2d30EP5gwg@mail.gmail.com>
	<4D4B6E28.4010209@jcea.es>
	<1296822354.3774.3.camel@localhost.localdomain>
	<20110204143019.5B3DB241BF5@kimball.webabinitio.net>
	<AANLkTi=YZWdf-OMK64=Gh1uKur2CGPvac7GD0ouOq+-r@mail.gmail.com>
	<AANLkTim0CmO33LXZhD_2F94=21WO8kv2=zBqSmN2FJXw@mail.gmail.com>
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 <ncoghlan at gmail.com> 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
> <branch> 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: <AANLkTim0CmO33LXZhD_2F94=21WO8kv2=zBqSmN2FJXw@mail.gmail.com>
References: <E7CDB684-105A-4783-B5D4-86D2E89E0701@holdenweb.com>
	<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>
	<AANLkTi=Rn7e8=tV+cN9Gj=LJgEgBPsHqxO2d30EP5gwg@mail.gmail.com>
	<4D4B6E28.4010209@jcea.es>
	<1296822354.3774.3.camel@localhost.localdomain>
	<20110204143019.5B3DB241BF5@kimball.webabinitio.net>
	<AANLkTi=YZWdf-OMK64=Gh1uKur2CGPvac7GD0ouOq+-r@mail.gmail.com>
	<AANLkTim0CmO33LXZhD_2F94=21WO8kv2=zBqSmN2FJXw@mail.gmail.com>
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 <ncoghlan at gmail.com> 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
><branch> 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: <http://mail.python.org/pipermail/python-committers/attachments/20110204/0dbefe95/attachment.pgp>

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: <E7CDB684-105A-4783-B5D4-86D2E89E0701@holdenweb.com>
	<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>
	<AANLkTi=Rn7e8=tV+cN9Gj=LJgEgBPsHqxO2d30EP5gwg@mail.gmail.com>
	<4D4B6E28.4010209@jcea.es>
	<1296822354.3774.3.camel@localhost.localdomain>
	<20110204143019.5B3DB241BF5@kimball.webabinitio.net>
	<AANLkTi=YZWdf-OMK64=Gh1uKur2CGPvac7GD0ouOq+-r@mail.gmail.com>
	<AANLkTim0CmO33LXZhD_2F94=21WO8kv2=zBqSmN2FJXw@mail.gmail.com>
	<1296837094.3774.10.camel@localhost.localdomain>
Message-ID: <AANLkTimyVs9iQumUMrM1vbLXd8gn2ak6=DUjWo8nD96X@mail.gmail.com>

On Fri, Feb 4, 2011 at 17:31, Antoine Pitrou <solipsis at pitrou.net> wrote:
>> That's exactly the idea of the Mercurial way. You type hg merge
>> <branch> 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: <E7CDB684-105A-4783-B5D4-86D2E89E0701@holdenweb.com>
	<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>
	<AANLkTi=Rn7e8=tV+cN9Gj=LJgEgBPsHqxO2d30EP5gwg@mail.gmail.com>
	<4D4B6E28.4010209@jcea.es>
	<1296822354.3774.3.camel@localhost.localdomain>
	<20110204143019.5B3DB241BF5@kimball.webabinitio.net>
	<AANLkTi=YZWdf-OMK64=Gh1uKur2CGPvac7GD0ouOq+-r@mail.gmail.com>
	<AANLkTim0CmO33LXZhD_2F94=21WO8kv2=zBqSmN2FJXw@mail.gmail.com>
	<20110204113610.7afd1a90@python.org>
Message-ID: <AANLkTimHLCid1MPPJs5AtsXns-OdKC=YmsC_NehHihX8@mail.gmail.com>

On Fri, Feb 4, 2011 at 17:36, Barry Warsaw <barry at python.org> 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: <AANLkTimHLCid1MPPJs5AtsXns-OdKC=YmsC_NehHihX8@mail.gmail.com>
References: <E7CDB684-105A-4783-B5D4-86D2E89E0701@holdenweb.com>
	<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>
	<AANLkTi=Rn7e8=tV+cN9Gj=LJgEgBPsHqxO2d30EP5gwg@mail.gmail.com>
	<4D4B6E28.4010209@jcea.es>
	<1296822354.3774.3.camel@localhost.localdomain>
	<20110204143019.5B3DB241BF5@kimball.webabinitio.net>
	<AANLkTi=YZWdf-OMK64=Gh1uKur2CGPvac7GD0ouOq+-r@mail.gmail.com>
	<AANLkTim0CmO33LXZhD_2F94=21WO8kv2=zBqSmN2FJXw@mail.gmail.com>
	<20110204113610.7afd1a90@python.org>
	<AANLkTimHLCid1MPPJs5AtsXns-OdKC=YmsC_NehHihX8@mail.gmail.com>
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: <http://mail.python.org/pipermail/python-committers/attachments/20110204/2e6dfd9b/attachment.pgp>

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: <E7CDB684-105A-4783-B5D4-86D2E89E0701@holdenweb.com>
	<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>
	<AANLkTi=Rn7e8=tV+cN9Gj=LJgEgBPsHqxO2d30EP5gwg@mail.gmail.com>
	<4D4B6E28.4010209@jcea.es>
	<1296822354.3774.3.camel@localhost.localdomain>
	<20110204143019.5B3DB241BF5@kimball.webabinitio.net>
	<AANLkTi=YZWdf-OMK64=Gh1uKur2CGPvac7GD0ouOq+-r@mail.gmail.com>
	<AANLkTim0CmO33LXZhD_2F94=21WO8kv2=zBqSmN2FJXw@mail.gmail.com>
	<20110204113610.7afd1a90@python.org>
	<AANLkTimHLCid1MPPJs5AtsXns-OdKC=YmsC_NehHihX8@mail.gmail.com>
	<20110204115115.7247130a@python.org>
Message-ID: <AANLkTi=X=SzOEYV7TCF+uijck_LzgY3Lb7PbXsVFxv6Q@mail.gmail.com>

On Fri, Feb 4, 2011 at 17:51, Barry Warsaw <barry at python.org> 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: <AANLkTi=X=SzOEYV7TCF+uijck_LzgY3Lb7PbXsVFxv6Q@mail.gmail.com>
References: <E7CDB684-105A-4783-B5D4-86D2E89E0701@holdenweb.com>	<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>	<AANLkTi=Rn7e8=tV+cN9Gj=LJgEgBPsHqxO2d30EP5gwg@mail.gmail.com>	<4D4B6E28.4010209@jcea.es>	<1296822354.3774.3.camel@localhost.localdomain>	<20110204143019.5B3DB241BF5@kimball.webabinitio.net>	<AANLkTi=YZWdf-OMK64=Gh1uKur2CGPvac7GD0ouOq+-r@mail.gmail.com>	<AANLkTim0CmO33LXZhD_2F94=21WO8kv2=zBqSmN2FJXw@mail.gmail.com>	<20110204113610.7afd1a90@python.org>	<AANLkTimHLCid1MPPJs5AtsXns-OdKC=YmsC_NehHihX8@mail.gmail.com>	<20110204115115.7247130a@python.org>
	<AANLkTi=X=SzOEYV7TCF+uijck_LzgY3Lb7PbXsVFxv6Q@mail.gmail.com>
Message-ID: <iiheiq$o10$1@dough.gmane.org>

Am 04.02.2011 18:03, schrieb Dirkjan Ochtman:
> On Fri, Feb 4, 2011 at 17:51, Barry Warsaw <barry at python.org> 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: <AANLkTi=YZWdf-OMK64=Gh1uKur2CGPvac7GD0ouOq+-r@mail.gmail.com>
References: <E7CDB684-105A-4783-B5D4-86D2E89E0701@holdenweb.com>	<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>	<AANLkTi=Rn7e8=tV+cN9Gj=LJgEgBPsHqxO2d30EP5gwg@mail.gmail.com>	<4D4B6E28.4010209@jcea.es>	<1296822354.3774.3.camel@localhost.localdomain>	<20110204143019.5B3DB241BF5@kimball.webabinitio.net>
	<AANLkTi=YZWdf-OMK64=Gh1uKur2CGPvac7GD0ouOq+-r@mail.gmail.com>
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>	<AANLkTi=MnReyridDcwEaEMVY=c=0PitgU+u8che9ngsc@mail.gmail.com>	<4D4C03C9.5070308@jcea.es>	<AANLkTimDOM3zQoePE+Y4qKftfa6dLwjGx=G=OpzOZ2nb@mail.gmail.com>	<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: <E7CDB684-105A-4783-B5D4-86D2E89E0701@holdenweb.com>	<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>	<AANLkTi=Rn7e8=tV+cN9Gj=LJgEgBPsHqxO2d30EP5gwg@mail.gmail.com>	<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: <E7CDB684-105A-4783-B5D4-86D2E89E0701@holdenweb.com>	<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>	<AANLkTi=Rn7e8=tV+cN9Gj=LJgEgBPsHqxO2d30EP5gwg@mail.gmail.com>	<4D4B6E28.4010209@jcea.es>	<1296822354.3774.3.camel@localhost.localdomain>	<20110204143019.5B3DB241BF5@kimball.webabinitio.net>	<AANLkTi=YZWdf-OMK64=Gh1uKur2CGPvac7GD0ouOq+-r@mail.gmail.com>	<AANLkTim0CmO33LXZhD_2F94=21WO8kv2=zBqSmN2FJXw@mail.gmail.com>
	<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: <E7CDB684-105A-4783-B5D4-86D2E89E0701@holdenweb.com>	<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>	<AANLkTi=Rn7e8=tV+cN9Gj=LJgEgBPsHqxO2d30EP5gwg@mail.gmail.com>	<4D4B6E28.4010209@jcea.es>	<1296822354.3774.3.camel@localhost.localdomain>	<20110204143019.5B3DB241BF5@kimball.webabinitio.net>	<AANLkTi=YZWdf-OMK64=Gh1uKur2CGPvac7GD0ouOq+-r@mail.gmail.com>	<AANLkTim0CmO33LXZhD_2F94=21WO8kv2=zBqSmN2FJXw@mail.gmail.com>	<20110204113610.7afd1a90@python.org>	<AANLkTimHLCid1MPPJs5AtsXns-OdKC=YmsC_NehHihX8@mail.gmail.com>
	<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: <E7CDB684-105A-4783-B5D4-86D2E89E0701@holdenweb.com>
	<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>
	<AANLkTi=Rn7e8=tV+cN9Gj=LJgEgBPsHqxO2d30EP5gwg@mail.gmail.com>
	<4D4B6E28.4010209@jcea.es>	<1296822354.3774.3.camel@localhost.localdomain>
	<20110204143019.5B3DB241BF5@kimball.webabinitio.net>
	<AANLkTi=YZWdf-OMK64=Gh1uKur2CGPvac7GD0ouOq+-r@mail.gmail.com>
	<AANLkTim0CmO33LXZhD_2F94=21WO8kv2=zBqSmN2FJXw@mail.gmail.com>
	<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: <E7CDB684-105A-4783-B5D4-86D2E89E0701@holdenweb.com>	<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>	<AANLkTi=Rn7e8=tV+cN9Gj=LJgEgBPsHqxO2d30EP5gwg@mail.gmail.com>	<4D4B6E28.4010209@jcea.es>	<1296822354.3774.3.camel@localhost.localdomain>	<20110204143019.5B3DB241BF5@kimball.webabinitio.net>	<AANLkTi=YZWdf-OMK64=Gh1uKur2CGPvac7GD0ouOq+-r@mail.gmail.com>	<AANLkTim0CmO33LXZhD_2F94=21WO8kv2=zBqSmN2FJXw@mail.gmail.com>	<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: <E7CDB684-105A-4783-B5D4-86D2E89E0701@holdenweb.com>
	<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>
	<AANLkTi=Rn7e8=tV+cN9Gj=LJgEgBPsHqxO2d30EP5gwg@mail.gmail.com>
	<4D4B6E28.4010209@jcea.es>	<1296822354.3774.3.camel@localhost.localdomain>
	<20110204143019.5B3DB241BF5@kimball.webabinitio.net>
	<AANLkTi=YZWdf-OMK64=Gh1uKur2CGPvac7GD0ouOq+-r@mail.gmail.com>
	<AANLkTim0CmO33LXZhD_2F94=21WO8kv2=zBqSmN2FJXw@mail.gmail.com>
	<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: <E7CDB684-105A-4783-B5D4-86D2E89E0701@holdenweb.com>
	<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>
	<AANLkTi=Rn7e8=tV+cN9Gj=LJgEgBPsHqxO2d30EP5gwg@mail.gmail.com>
	<4D4B6E28.4010209@jcea.es>	<1296822354.3774.3.camel@localhost.localdomain>
	<20110204143019.5B3DB241BF5@kimball.webabinitio.net>
	<AANLkTi=YZWdf-OMK64=Gh1uKur2CGPvac7GD0ouOq+-r@mail.gmail.com>
	<AANLkTim0CmO33LXZhD_2F94=21WO8kv2=zBqSmN2FJXw@mail.gmail.com>
	<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: <E7CDB684-105A-4783-B5D4-86D2E89E0701@holdenweb.com>	<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>	<AANLkTi=Rn7e8=tV+cN9Gj=LJgEgBPsHqxO2d30EP5gwg@mail.gmail.com>	<4D4B6E28.4010209@jcea.es>	<1296822354.3774.3.camel@localhost.localdomain>	<20110204143019.5B3DB241BF5@kimball.webabinitio.net>	<AANLkTi=YZWdf-OMK64=Gh1uKur2CGPvac7GD0ouOq+-r@mail.gmail.com>	<AANLkTim0CmO33LXZhD_2F94=21WO8kv2=zBqSmN2FJXw@mail.gmail.com>	<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: <E7CDB684-105A-4783-B5D4-86D2E89E0701@holdenweb.com>
	<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>
	<AANLkTi=Rn7e8=tV+cN9Gj=LJgEgBPsHqxO2d30EP5gwg@mail.gmail.com>
	<4D4B6E28.4010209@jcea.es>	<1296822354.3774.3.camel@localhost.localdomain>
	<20110204143019.5B3DB241BF5@kimball.webabinitio.net>
	<AANLkTi=YZWdf-OMK64=Gh1uKur2CGPvac7GD0ouOq+-r@mail.gmail.com>
	<AANLkTim0CmO33LXZhD_2F94=21WO8kv2=zBqSmN2FJXw@mail.gmail.com>
	<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: <E7CDB684-105A-4783-B5D4-86D2E89E0701@holdenweb.com>	<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>	<AANLkTikYpdtvn1aePt+PAfZaqtfEer+pSJVP2JEABncL@mail.gmail.com>
	<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: <AANLkTikYpdtvn1aePt+PAfZaqtfEer+pSJVP2JEABncL@mail.gmail.com>
References: <E7CDB684-105A-4783-B5D4-86D2E89E0701@holdenweb.com>	<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>
	<AANLkTikYpdtvn1aePt+PAfZaqtfEer+pSJVP2JEABncL@mail.gmail.com>
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: <E7CDB684-105A-4783-B5D4-86D2E89E0701@holdenweb.com>	<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>	<AANLkTi=Rn7e8=tV+cN9Gj=LJgEgBPsHqxO2d30EP5gwg@mail.gmail.com>	<4D4B6E28.4010209@jcea.es>	<1296822354.3774.3.camel@localhost.localdomain>	<20110204143019.5B3DB241BF5@kimball.webabinitio.net>	<AANLkTi=YZWdf-OMK64=Gh1uKur2CGPvac7GD0ouOq+-r@mail.gmail.com>	<AANLkTim0CmO33LXZhD_2F94=21WO8kv2=zBqSmN2FJXw@mail.gmail.com>	<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: <AANLkTi=hoc1=UGsJViWO3kHymV5zhqVt4rqL3=j54mPZ@mail.gmail.com>
References: <E7CDB684-105A-4783-B5D4-86D2E89E0701@holdenweb.com>	<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>	<AANLkTi=Rn7e8=tV+cN9Gj=LJgEgBPsHqxO2d30EP5gwg@mail.gmail.com>	<1296735633.3705.3.camel@localhost.localdomain>	<AANLkTimrR4M7H-PZ50fcc0DQk7zuq70YvyMFs9FEJRbP@mail.gmail.com>	<4D4B6FE2.8000808@jcea.es>
	<AANLkTi=hoc1=UGsJViWO3kHymV5zhqVt4rqL3=j54mPZ@mail.gmail.com>
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 <jcea at jcea.es> 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: <E7CDB684-105A-4783-B5D4-86D2E89E0701@holdenweb.com>
	<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>
	<AANLkTi=Rn7e8=tV+cN9Gj=LJgEgBPsHqxO2d30EP5gwg@mail.gmail.com>
	<4D4B6E28.4010209@jcea.es>	<1296822354.3774.3.camel@localhost.localdomain>
	<20110204143019.5B3DB241BF5@kimball.webabinitio.net>
	<AANLkTi=YZWdf-OMK64=Gh1uKur2CGPvac7GD0ouOq+-r@mail.gmail.com>
	<AANLkTim0CmO33LXZhD_2F94=21WO8kv2=zBqSmN2FJXw@mail.gmail.com>
	<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: <E7CDB684-105A-4783-B5D4-86D2E89E0701@holdenweb.com>	<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>	<AANLkTi=Rn7e8=tV+cN9Gj=LJgEgBPsHqxO2d30EP5gwg@mail.gmail.com>	<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: <E7CDB684-105A-4783-B5D4-86D2E89E0701@holdenweb.com>	<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>	<AANLkTi=Rn7e8=tV+cN9Gj=LJgEgBPsHqxO2d30EP5gwg@mail.gmail.com>	<4D4B6E28.4010209@jcea.es>	<1296822354.3774.3.camel@localhost.localdomain>	<20110204143019.5B3DB241BF5@kimball.webabinitio.net>	<AANLkTi=YZWdf-OMK64=Gh1uKur2CGPvac7GD0ouOq+-r@mail.gmail.com>	<AANLkTim0CmO33LXZhD_2F94=21WO8kv2=zBqSmN2FJXw@mail.gmail.com>	<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: <E7CDB684-105A-4783-B5D4-86D2E89E0701@holdenweb.com>
	<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>
	<AANLkTi=Rn7e8=tV+cN9Gj=LJgEgBPsHqxO2d30EP5gwg@mail.gmail.com>
	<4D4B6E28.4010209@jcea.es>
	<1296822354.3774.3.camel@localhost.localdomain>
	<20110204143019.5B3DB241BF5@kimball.webabinitio.net>
	<AANLkTi=YZWdf-OMK64=Gh1uKur2CGPvac7GD0ouOq+-r@mail.gmail.com>
	<AANLkTim0CmO33LXZhD_2F94=21WO8kv2=zBqSmN2FJXw@mail.gmail.com>
	<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: <AANLkTimWL1ZdH9_JbLhFpOJWfcJW7noTcXJdF+t-vFzB@mail.gmail.com>

On Sat, Feb 5, 2011 at 10:00 AM, Jesus Cea <jcea at jcea.es> 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: <E7CDB684-105A-4783-B5D4-86D2E89E0701@holdenweb.com>
	<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>
	<AANLkTikYpdtvn1aePt+PAfZaqtfEer+pSJVP2JEABncL@mail.gmail.com>
	<4D4CA2E8.3030506@v.loewis.de>
Message-ID: <20110205180851.0E3EC21DC0B@kimball.webabinitio.net>

On Sat, 05 Feb 2011 02:07:52 +0100, <martin at v.loewis.de> 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: <E7CDB684-105A-4783-B5D4-86D2E89E0701@holdenweb.com>
	<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>
	<AANLkTikYpdtvn1aePt+PAfZaqtfEer+pSJVP2JEABncL@mail.gmail.com>
	<4D4CA2E8.3030506@v.loewis.de>
	<20110205180851.0E3EC21DC0B@kimball.webabinitio.net>
Message-ID: <AANLkTinQzRqAGhM9dQ0SB4wkzHuYszVD_aOQNTGKXO2O@mail.gmail.com>

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 <rdmurray at bitdance.com> wrote:
> On Sat, 05 Feb 2011 02:07:52 +0100, <martin at v.loewis.de> 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: <E7CDB684-105A-4783-B5D4-86D2E89E0701@holdenweb.com>
	<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>
	<AANLkTikYpdtvn1aePt+PAfZaqtfEer+pSJVP2JEABncL@mail.gmail.com>
	<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: <AANLkTinQzRqAGhM9dQ0SB4wkzHuYszVD_aOQNTGKXO2O@mail.gmail.com>
References: <E7CDB684-105A-4783-B5D4-86D2E89E0701@holdenweb.com>
	<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>
	<AANLkTikYpdtvn1aePt+PAfZaqtfEer+pSJVP2JEABncL@mail.gmail.com>
	<4D4CA2E8.3030506@v.loewis.de>
	<20110205180851.0E3EC21DC0B@kimball.webabinitio.net>
	<AANLkTinQzRqAGhM9dQ0SB4wkzHuYszVD_aOQNTGKXO2O@mail.gmail.com>
Message-ID: <AANLkTi=bhmMBggD-d3m6kr99+H=tJ9+s2AA3n2GZ12+j@mail.gmail.com>

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 <brett at python.org> 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 <rdmurray at bitdance.com> wrote:
>> On Sat, 05 Feb 2011 02:07:52 +0100, <martin at v.loewis.de> 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: <AANLkTi=bhmMBggD-d3m6kr99+H=tJ9+s2AA3n2GZ12+j@mail.gmail.com>
References: <E7CDB684-105A-4783-B5D4-86D2E89E0701@holdenweb.com>	<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>	<AANLkTikYpdtvn1aePt+PAfZaqtfEer+pSJVP2JEABncL@mail.gmail.com>	<4D4CA2E8.3030506@v.loewis.de>	<20110205180851.0E3EC21DC0B@kimball.webabinitio.net>	<AANLkTinQzRqAGhM9dQ0SB4wkzHuYszVD_aOQNTGKXO2O@mail.gmail.com>
	<AANLkTi=bhmMBggD-d3m6kr99+H=tJ9+s2AA3n2GZ12+j@mail.gmail.com>
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: <E7CDB684-105A-4783-B5D4-86D2E89E0701@holdenweb.com>
	<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>
	<AANLkTikYpdtvn1aePt+PAfZaqtfEer+pSJVP2JEABncL@mail.gmail.com>
	<4D4CA2E8.3030506@v.loewis.de>
	<20110205180851.0E3EC21DC0B@kimball.webabinitio.net>
	<AANLkTinQzRqAGhM9dQ0SB4wkzHuYszVD_aOQNTGKXO2O@mail.gmail.com>
	<AANLkTi=bhmMBggD-d3m6kr99+H=tJ9+s2AA3n2GZ12+j@mail.gmail.com>
	<4D4E1F79.4030800@jcea.es>
Message-ID: <AANLkTi=OLdMyWzfeUFQo4vac7F+HxPag1L30uA5gjJcB@mail.gmail.com>

On Sun, Feb 6, 2011 at 2:11 PM, Jesus Cea <jcea at jcea.es> 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: <AANLkTi=bhmMBggD-d3m6kr99+H=tJ9+s2AA3n2GZ12+j@mail.gmail.com>
References: <E7CDB684-105A-4783-B5D4-86D2E89E0701@holdenweb.com>
	<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>
	<AANLkTikYpdtvn1aePt+PAfZaqtfEer+pSJVP2JEABncL@mail.gmail.com>
	<4D4CA2E8.3030506@v.loewis.de>
	<20110205180851.0E3EC21DC0B@kimball.webabinitio.net>
	<AANLkTinQzRqAGhM9dQ0SB4wkzHuYszVD_aOQNTGKXO2O@mail.gmail.com>
	<AANLkTi=bhmMBggD-d3m6kr99+H=tJ9+s2AA3n2GZ12+j@mail.gmail.com>
Message-ID: <AANLkTimqekMhH73VVU7MPxyBeOb_DrcWZBGe61MKTFu+@mail.gmail.com>

On Sun, Feb 6, 2011 at 1:21 PM, Brett Cannon <brett at python.org> 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: <E7CDB684-105A-4783-B5D4-86D2E89E0701@holdenweb.com>
	<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>
	<AANLkTikYpdtvn1aePt+PAfZaqtfEer+pSJVP2JEABncL@mail.gmail.com>
	<4D4CA2E8.3030506@v.loewis.de>
	<20110205180851.0E3EC21DC0B@kimball.webabinitio.net>
	<4D4DAF35.4010705@v.loewis.de>
Message-ID: <AANLkTi=vtYgUYVJj=s+Ry4WA6716YtnhaZYtkALnhtQz@mail.gmail.com>

On Sat, Feb 5, 2011 at 12:12 PM, "Martin v. L?wis" <martin at v.loewis.de>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: <http://mail.python.org/pipermail/python-committers/attachments/20110207/8bc68b06/attachment.html>

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: <AANLkTi=vtYgUYVJj=s+Ry4WA6716YtnhaZYtkALnhtQz@mail.gmail.com>
References: <E7CDB684-105A-4783-B5D4-86D2E89E0701@holdenweb.com>
	<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>
	<AANLkTikYpdtvn1aePt+PAfZaqtfEer+pSJVP2JEABncL@mail.gmail.com>
	<4D4CA2E8.3030506@v.loewis.de>
	<20110205180851.0E3EC21DC0B@kimball.webabinitio.net>
	<4D4DAF35.4010705@v.loewis.de>
	<AANLkTi=vtYgUYVJj=s+Ry4WA6716YtnhaZYtkALnhtQz@mail.gmail.com>
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"
> <martin at v.loewis.de> 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: <E7CDB684-105A-4783-B5D4-86D2E89E0701@holdenweb.com>
	<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>
	<AANLkTikYpdtvn1aePt+PAfZaqtfEer+pSJVP2JEABncL@mail.gmail.com>
	<4D4CA2E8.3030506@v.loewis.de>
	<20110205180851.0E3EC21DC0B@kimball.webabinitio.net>
	<4D4DAF35.4010705@v.loewis.de>
	<AANLkTi=vtYgUYVJj=s+Ry4WA6716YtnhaZYtkALnhtQz@mail.gmail.com>
	<1297099787.3754.29.camel@localhost.localdomain>
Message-ID: <AANLkTi=9bbVif7SmpaFhcqu8+pcm03vv5XW6DRnAv+PL@mail.gmail.com>

On Tue, Feb 8, 2011 at 3:29 AM, Antoine Pitrou <solipsis at pitrou.net> 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: <iitfvv$pcu$1@dough.gmane.org>

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: <loom.20110212T152558-868@post.gmane.org>

Hi Georg,

Georg Brandl <georg <at> 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: <loom.20110212T152558-868@post.gmane.org>
References: <4D4534CE.4010509@python.org> <4D45CE49.8010909@python.org>
	<loom.20110212T152558-868@post.gmane.org>
Message-ID: <ij732n$n3o$1@dough.gmane.org>

Am 12.02.2011 15:28, schrieb Vinay Sajip:
> Hi Georg,
> 
> Georg Brandl <georg <at> 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: <ij89gd$sld$1@dough.gmane.org>

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>
	<loom.20110212T152558-868@post.gmane.org>
	<ij732n$n3o$1@dough.gmane.org>
Message-ID: <loom.20110213T132017-859@post.gmane.org>

Georg Brandl <g.brandl <at> 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: <loom.20110213T132017-859@post.gmane.org>
References: <4D4534CE.4010509@python.org> <4D45CE49.8010909@python.org>
	<loom.20110212T152558-868@post.gmane.org>
	<ij732n$n3o$1@dough.gmane.org>
	<loom.20110213T132017-859@post.gmane.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>	<loom.20110212T152558-868@post.gmane.org>	<ij732n$n3o$1@dough.gmane.org>	<loom.20110213T132017-859@post.gmane.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>	<loom.20110212T152558-868@post.gmane.org>	<ij732n$n3o$1@dough.gmane.org>	<loom.20110213T132017-859@post.gmane.org>
	<20110213134239.GA12042@ubuntu>
Message-ID: <ij8p1r$vp9$1@dough.gmane.org>

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>
	<loom.20110212T152558-868@post.gmane.org>
	<ij732n$n3o$1@dough.gmane.org>
	<loom.20110213T132017-859@post.gmane.org>
	<20110213134239.GA12042@ubuntu> <4D57E025.5010604@python.org>
Message-ID: <AANLkTinpwdaerQeygb024TfCB3iDZTkb0fNjeSRJCS=n@mail.gmail.com>

On Sun, Feb 13, 2011 at 9:44 PM, Michael Foord <mfoord at python.org> 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: <ijh2vc$ojg$1@dough.gmane.org>

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: <AANLkTinAgjaNBzeG392Kt91yeVtod46OkwwsDWXight6@mail.gmail.com>

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: <AANLkTinAgjaNBzeG392Kt91yeVtod46OkwwsDWXight6@mail.gmail.com>
References: <AANLkTinAgjaNBzeG392Kt91yeVtod46OkwwsDWXight6@mail.gmail.com>
Message-ID: <AANLkTikm8ei-2bgvU04CmaHPqRtAPiavrWQHXxZ-Oj-u@mail.gmail.com>

On Fri, Feb 18, 2011 at 3:36 PM, Brett Cannon <brett at python.org> 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.? ? <fdrake at acm.org>
"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: <AANLkTinAgjaNBzeG392Kt91yeVtod46OkwwsDWXight6@mail.gmail.com>
References: <AANLkTinAgjaNBzeG392Kt91yeVtod46OkwwsDWXight6@mail.gmail.com>
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: <AANLkTinAgjaNBzeG392Kt91yeVtod46OkwwsDWXight6@mail.gmail.com>
	<1298062767.3761.16.camel@localhost.localdomain>
Message-ID: <AANLkTinuNJQxSnUjYgpLn=mua6MEs6io--XyMftLCZRG@mail.gmail.com>

On Fri, Feb 18, 2011 at 3:59 PM, Antoine Pitrou <solipsis at pitrou.net> 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.? ? <fdrake at acm.org>
"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: <AANLkTinAgjaNBzeG392Kt91yeVtod46OkwwsDWXight6@mail.gmail.com>
References: <AANLkTinAgjaNBzeG392Kt91yeVtod46OkwwsDWXight6@mail.gmail.com>
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: <AANLkTinAgjaNBzeG392Kt91yeVtod46OkwwsDWXight6@mail.gmail.com>
References: <AANLkTinAgjaNBzeG392Kt91yeVtod46OkwwsDWXight6@mail.gmail.com>
Message-ID: <AANLkTimfOWCBUZpU46SxQsadOZa9FVDGKj-ki00T24tU@mail.gmail.com>

On Fri, Feb 18, 2011 at 3:36 PM, Brett Cannon <brett at python.org> 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: <AANLkTinAgjaNBzeG392Kt91yeVtod46OkwwsDWXight6@mail.gmail.com>
	<4D5EE627.6040705@egenix.com>
Message-ID: <AANLkTinF0G12xshKS1EURka+REmezL1U=q=bmTHOiU==@mail.gmail.com>

On Fri, Feb 18, 2011 at 10:35 PM, M.-A. Lemburg <mal at egenix.com> 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: <AANLkTinAgjaNBzeG392Kt91yeVtod46OkwwsDWXight6@mail.gmail.com>
References: <AANLkTinAgjaNBzeG392Kt91yeVtod46OkwwsDWXight6@mail.gmail.com>
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: <AANLkTinAgjaNBzeG392Kt91yeVtod46OkwwsDWXight6@mail.gmail.com>
	<32370E2F-3933-4820-AEFF-3F4DBC716996@gmail.com>
Message-ID: <AANLkTimtv4V6=5_p5sE-25BfzYWju4c_yVfMQot-q5nT@mail.gmail.com>

On Sat, Feb 19, 2011 at 11:30 AM, Raymond Hettinger
<raymond.hettinger at gmail.com> 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: <ijqpgb$jba$1@dough.gmane.org>

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: <iju9uv$8g1$1@dough.gmane.org>

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: <iju9uv$8g1$1@dough.gmane.org>
References: <iju9uv$8g1$1@dough.gmane.org>
Message-ID: <ijua4b$8g1$2@dough.gmane.org>

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: <iju9uv$8g1$1@dough.gmane.org>
References: <iju9uv$8g1$1@dough.gmane.org>
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: <iju9uv$8g1$1@dough.gmane.org> <4D62ADFD.1050502@udel.edu>
Message-ID: <ijugj5$emb$1@dough.gmane.org>

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: <iju9uv$8g1$1@dough.gmane.org>
References: <iju9uv$8g1$1@dough.gmane.org>
Message-ID: <AANLkTinNOdUHkorcfj8GP=roO_k=Ht1U_+23eL_j3Pvg@mail.gmail.com>

2011/2/21 Georg Brandl <g.brandl at gmx.net>:
> 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: <AANLkTinAgjaNBzeG392Kt91yeVtod46OkwwsDWXight6@mail.gmail.com>
References: <AANLkTinAgjaNBzeG392Kt91yeVtod46OkwwsDWXight6@mail.gmail.com>
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: <http://mail.python.org/pipermail/python-committers/attachments/20110223/288ab898/attachment.pgp>

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: <AANLkTinAgjaNBzeG392Kt91yeVtod46OkwwsDWXight6@mail.gmail.com>
	<20110223181330.0525f2e3@python.org>
Message-ID: <AANLkTimJkPwCocVFMQ_dcHUgdvS+F5QtjXTmFiUtFVo_@mail.gmail.com>

On Wed, Feb 23, 2011 at 15:13, Barry Warsaw <barry at python.org> 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: <http://mail.python.org/pipermail/python-committers/attachments/20110223/a0aa50bb/attachment.html>

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: <AANLkTikj=iGh5qLAHv5VK3oSRouR7sWx=1xuVr6Rt6Gi@mail.gmail.com>

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: <http://mail.python.org/pipermail/python-committers/attachments/20110223/86c111d9/attachment.html>

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: <AANLkTimJkPwCocVFMQ_dcHUgdvS+F5QtjXTmFiUtFVo_@mail.gmail.com>
References: <AANLkTinAgjaNBzeG392Kt91yeVtod46OkwwsDWXight6@mail.gmail.com>
	<20110223181330.0525f2e3@python.org>
	<AANLkTimJkPwCocVFMQ_dcHUgdvS+F5QtjXTmFiUtFVo_@mail.gmail.com>
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: <http://mail.python.org/pipermail/python-committers/attachments/20110223/f6c026fd/attachment.pgp>

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: <AANLkTikQ8wr5FNDMEeBR+EAdEQsCE6ZTYiXB+7b1hM6d@mail.gmail.com>
References: <AANLkTikQ8wr5FNDMEeBR+EAdEQsCE6ZTYiXB+7b1hM6d@mail.gmail.com>
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: <AANLkTinAgjaNBzeG392Kt91yeVtod46OkwwsDWXight6@mail.gmail.com>
	<20110223181330.0525f2e3@python.org>
Message-ID: <AANLkTikO1Xz1D6c1eB_X5j9=0RTH2oB8_tbMyxmEiDpc@mail.gmail.com>

On Thu, Feb 24, 2011 at 9:13 AM, Barry Warsaw <barry at python.org> 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: <AANLkTinWcdJRmuHj8Va5KuOmjjMBt+=48YueCtDobqAE@mail.gmail.com>

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: <http://mail.python.org/pipermail/python-committers/attachments/20110224/fc97072e/attachment.html>

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: <AANLkTinWcdJRmuHj8Va5KuOmjjMBt+=48YueCtDobqAE@mail.gmail.com>
References: <AANLkTinWcdJRmuHj8Va5KuOmjjMBt+=48YueCtDobqAE@mail.gmail.com>
Message-ID: <AANLkTimeyq4k8Ue4FGLoXM1h5jvz11pF-X6CxHgrZahw@mail.gmail.com>

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 <brian.curtin at gmail.com> 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: <http://mail.python.org/pipermail/python-committers/attachments/20110224/ecc68c7d/attachment.html>

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: <AANLkTimeyq4k8Ue4FGLoXM1h5jvz11pF-X6CxHgrZahw@mail.gmail.com>
References: <AANLkTinWcdJRmuHj8Va5KuOmjjMBt+=48YueCtDobqAE@mail.gmail.com>
	<AANLkTimeyq4k8Ue4FGLoXM1h5jvz11pF-X6CxHgrZahw@mail.gmail.com>
Message-ID: <FFE7C07E-8B2B-40ED-9BC6-942B9FF5E5E0@langa.pl>

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: <http://mail.python.org/pipermail/python-committers/attachments/20110224/5b218fab/attachment.html>

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: <FFE7C07E-8B2B-40ED-9BC6-942B9FF5E5E0@langa.pl>
References: <AANLkTinWcdJRmuHj8Va5KuOmjjMBt+=48YueCtDobqAE@mail.gmail.com>
	<AANLkTimeyq4k8Ue4FGLoXM1h5jvz11pF-X6CxHgrZahw@mail.gmail.com>
	<FFE7C07E-8B2B-40ED-9BC6-942B9FF5E5E0@langa.pl>
Message-ID: <AANLkTikAMCaEgFyyG2q=2bvdkmSbJ6arHfWe7OfANgkc@mail.gmail.com>

Actually you should post it to the python-dev IRC group.

2011/2/24 ?ukasz Langa <lukasz at langa.pl>:
> 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)