From michael at voidspace.org.uk  Mon Apr  5 15:56:14 2010
From: michael at voidspace.org.uk (Michael Foord)
Date: Mon, 05 Apr 2010 14:56:14 +0100
Subject: [python-committers] Jean Paul-Calderone Commit Access
Message-ID: <4BB9EBFE.7090807@voidspace.org.uk>

Hello all,

I would like to propose Jean-Paul Calderone (exarkun) for commit access.

He is a core-twisted developer and a very experienced Python developer 
with a passionate belief in good testing. He also regularly comments the 
issue tracker. Twisted run their test framework against python-trunk, so 
he often reports compatibility issues they discover.

Patches he has already submitted include those on issues 658327, 5767, 
6844, 5485 and 639307.

I would be very happy to 'mentor' him, but don't think I qualify as I 
wouldn't be able to check C patches. He knows the Python workflow well 
enough though.

All the best,

Michael Foord

-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog

READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (?BOGUS AGREEMENTS?) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.



From barry at python.org  Mon Apr  5 16:19:08 2010
From: barry at python.org (Barry Warsaw)
Date: Mon, 5 Apr 2010 10:19:08 -0400
Subject: [python-committers] Jean Paul-Calderone Commit Access
In-Reply-To: <4BB9EBFE.7090807@voidspace.org.uk>
References: <4BB9EBFE.7090807@voidspace.org.uk>
Message-ID: <20100405101908.60de600e@heresy>

On Apr 05, 2010, at 02:56 PM, Michael Foord wrote:

>I would like to propose Jean-Paul Calderone (exarkun) for commit access.
>
>He is a core-twisted developer and a very experienced Python developer 
>with a passionate belief in good testing. He also regularly comments the 
>issue tracker. Twisted run their test framework against python-trunk, so 
>he often reports compatibility issues they discover.
>
>Patches he has already submitted include those on issues 658327, 5767, 
>6844, 5485 and 639307.
>
>I would be very happy to 'mentor' him, but don't think I qualify as I 
>wouldn't be able to check C patches. He knows the Python workflow well 
>enough though.

I think JP will need very little mentoring.  If he's signed the contributor
agreement, +1.

-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/20100405/3a45b5ea/attachment.pgp>

From bob at redivi.com  Mon Apr  5 16:24:48 2010
From: bob at redivi.com (Bob Ippolito)
Date: Mon, 5 Apr 2010 07:24:48 -0700
Subject: [python-committers] Jean Paul-Calderone Commit Access
In-Reply-To: <20100405101908.60de600e@heresy>
References: <4BB9EBFE.7090807@voidspace.org.uk>
	<20100405101908.60de600e@heresy>
Message-ID: <x2o6a36e7291004050724ideed6a14m566a7b6307fd204c@mail.gmail.com>

On Mon, Apr 5, 2010 at 7:19 AM, Barry Warsaw <barry at python.org> wrote:
> On Apr 05, 2010, at 02:56 PM, Michael Foord wrote:
>
>>I would like to propose Jean-Paul Calderone (exarkun) for commit access.
>>
>>He is a core-twisted developer and a very experienced Python developer
>>with a passionate belief in good testing. He also regularly comments the
>>issue tracker. Twisted run their test framework against python-trunk, so
>>he often reports compatibility issues they discover.
>>
>>Patches he has already submitted include those on issues 658327, 5767,
>>6844, 5485 and 639307.
>>
>>I would be very happy to 'mentor' him, but don't think I qualify as I
>>wouldn't be able to check C patches. He knows the Python workflow well
>>enough though.
>
> I think JP will need very little mentoring. ?If he's signed the contributor
> agreement, +1.
>
> -Barry

I agree completely, definitely +1

-bob

From jnoller at gmail.com  Mon Apr  5 16:24:56 2010
From: jnoller at gmail.com (Jesse Noller)
Date: Mon, 5 Apr 2010 10:24:56 -0400
Subject: [python-committers] Jean Paul-Calderone Commit Access
In-Reply-To: <20100405101908.60de600e@heresy>
References: <4BB9EBFE.7090807@voidspace.org.uk>
	<20100405101908.60de600e@heresy>
Message-ID: <t2s4222a8491004050724wa54789f8j576b82b2b502e36b@mail.gmail.com>

On Mon, Apr 5, 2010 at 10:19 AM, Barry Warsaw <barry at python.org> wrote:
> On Apr 05, 2010, at 02:56 PM, Michael Foord wrote:
>
>>I would like to propose Jean-Paul Calderone (exarkun) for commit access.
>>
>>He is a core-twisted developer and a very experienced Python developer
>>with a passionate belief in good testing. He also regularly comments the
>>issue tracker. Twisted run their test framework against python-trunk, so
>>he often reports compatibility issues they discover.
>>
>>Patches he has already submitted include those on issues 658327, 5767,
>>6844, 5485 and 639307.
>>
>>I would be very happy to 'mentor' him, but don't think I qualify as I
>>wouldn't be able to check C patches. He knows the Python workflow well
>>enough though.
>
> I think JP will need very little mentoring. ?If he's signed the contributor
> agreement, +1.
>

+1 here too

From ezio.melotti at gmail.com  Mon Apr  5 17:00:52 2010
From: ezio.melotti at gmail.com (Ezio Melotti)
Date: Mon, 05 Apr 2010 18:00:52 +0300
Subject: [python-committers] Jean Paul-Calderone Commit Access
In-Reply-To: <4BB9EBFE.7090807@voidspace.org.uk>
References: <4BB9EBFE.7090807@voidspace.org.uk>
Message-ID: <4BB9FB24.3090100@gmail.com>

On 05/04/2010 16.56, Michael Foord wrote:
> Hello all,
>
> I would like to propose Jean-Paul Calderone (exarkun) for commit access.
>
> He is a core-twisted developer and a very experienced Python developer 
> with a passionate belief in good testing. He also regularly comments 
> the issue tracker. Twisted run their test framework against 
> python-trunk, so he often reports compatibility issues they discover.
>
> Patches he has already submitted include those on issues 658327, 5767, 
> 6844, 5485 and 639307.
>
> I would be very happy to 'mentor' him, but don't think I qualify as I 
> wouldn't be able to check C patches. He knows the Python workflow well 
> enough though.
>
> All the best,
>
> Michael Foord
>

+1

From ziade.tarek at gmail.com  Mon Apr  5 17:04:05 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Mon, 5 Apr 2010 17:04:05 +0200
Subject: [python-committers] Jean Paul-Calderone Commit Access
In-Reply-To: <4BB9EBFE.7090807@voidspace.org.uk>
References: <4BB9EBFE.7090807@voidspace.org.uk>
Message-ID: <s2t94bdd2611004050804r7910b9f4i549687ec0a2a87d8@mail.gmail.com>

On Mon, Apr 5, 2010 at 3:56 PM, Michael Foord <michael at voidspace.org.uk> wrote:
> Hello all,
>
> I would like to propose Jean-Paul Calderone (exarkun) for commit access.

I am surprised he's not a commiter already.

+1

Tarek
-- 
Tarek Ziad? | http://ziade.org

From chris at simplistix.co.uk  Tue Apr  6 08:29:30 2010
From: chris at simplistix.co.uk (Chris Withers)
Date: Tue, 06 Apr 2010 07:29:30 +0100
Subject: [python-committers] Jean Paul-Calderone Commit Access
In-Reply-To: <s2t94bdd2611004050804r7910b9f4i549687ec0a2a87d8@mail.gmail.com>
References: <4BB9EBFE.7090807@voidspace.org.uk>
	<s2t94bdd2611004050804r7910b9f4i549687ec0a2a87d8@mail.gmail.com>
Message-ID: <4BBAD4CA.7020902@simplistix.co.uk>

Tarek Ziad? wrote:
> On Mon, Apr 5, 2010 at 3:56 PM, Michael Foord <michael at voidspace.org.uk> wrote:
>> Hello all,
>>
>> I would like to propose Jean-Paul Calderone (exarkun) for commit access.
> 
> I am surprised he's not a commiter already.

I'll second that ;-)

+1

Chris

-- 
Simplistix - Content Management, Batch Processing & Python Consulting
            - http://www.simplistix.co.uk

From solipsis at pitrou.net  Tue Apr  6 16:08:33 2010
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Tue, 06 Apr 2010 16:08:33 +0200
Subject: [python-committers] Jean Paul-Calderone Commit Access
In-Reply-To: <4BB9EBFE.7090807@voidspace.org.uk>
References: <4BB9EBFE.7090807@voidspace.org.uk>
Message-ID: <1270562913.3518.43.camel@localhost>


Hello,

> He is a core-twisted developer and a very experienced Python developer 
> with a passionate belief in good testing. He also regularly comments the 
> issue tracker. Twisted run their test framework against python-trunk, so 
> he often reports compatibility issues they discover.

I'd like to second Michael's opinion about Jean-Paul's competence,
especially on network and system matters.

> I would be very happy to 'mentor' him, but don't think I qualify as I 
> wouldn't be able to check C patches. He knows the Python workflow well 
> enough though.

I can mentor him if necessary.

Regards

Antoine.



From jcea at jcea.es  Tue Apr  6 20:39:11 2010
From: jcea at jcea.es (Jesus Cea)
Date: Tue, 06 Apr 2010 20:39:11 +0200
Subject: [python-committers] pybsddb 5.0.0 integration and 2.7beta1 schedule
Message-ID: <4BBB7FCF.30903@jcea.es>

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

Oracle just released Berkeley DB 5.0.21, with features like SQLite fa?ade.

I am now testing pybsddb 5.0.0, that supports BDB 5.0.x.

My original plan was to delay integration of pybsddb 5.x.x for 2.7.1
release, but Larry Hastings has a (sensible) request to migrate pybsddb
from CObject to Capsule for 2.7.0. Current pybsddb 5.0.0 already
contains that change.

I am reluctant to integrate the code change before beta1, because
although it should be transparent I don't want to risk a red buildbot,
even for 20 minutes, so close to beta1. Integrating it between beta1 and
beta2 would be riskless, but it would break API compatibility (because
the CObject->Capsule) change.

I don't know how many people depend of the pybsddb C api, although I
think that very little.

What should I do?. When is the beta1 window closed?

PS: I would need a couple of hours for integration, but beware timezone!
(Spain :).

- -- 
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.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQCVAwUBS7t/z5lgi5GaxT1NAQL1VAP+LxE4TdHnS9hJpMj3q3GZAKz5c8ho8p2U
mRpyMmIC7y9OUk5uLQYrYdGpIVVZgrCi47+Oo77lxV4tDHbbHbWXxCZcX5P1QosK
HyKYVGS3nYc25WGgQvmGCtmw9LTLhiF24NHQtyzQp7LvPgCJu/OLlILaBCuYs/xX
LxRJV0c9OxU=
=pv/P
-----END PGP SIGNATURE-----

From solipsis at pitrou.net  Tue Apr  6 22:12:00 2010
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Tue, 06 Apr 2010 22:12:00 +0200
Subject: [python-committers] pybsddb 5.0.0 integration and 2.7beta1
 schedule
In-Reply-To: <4BBB7FCF.30903@jcea.es>
References: <4BBB7FCF.30903@jcea.es>
Message-ID: <1270584720.3518.51.camel@localhost>


> My original plan was to delay integration of pybsddb 5.x.x for 2.7.1
> release

Bugfix releases are only for bug fixes, by definition. 2.7.1 shouldn't
receive such a change.

> I am reluctant to integrate the code change before beta1, because
> although it should be transparent I don't want to risk a red buildbot,
> even for 20 minutes, so close to beta1.

Why should it be "transparent"? Are you so confident that it won't bring
any new problems? Given that we are talking about a new major version
number, this sounds a bit optimistic.




From jcea at jcea.es  Tue Apr  6 22:45:59 2010
From: jcea at jcea.es (Jesus Cea)
Date: Tue, 06 Apr 2010 22:45:59 +0200
Subject: [python-committers] pybsddb 5.0.0 integration and 2.7beta1
	schedule
In-Reply-To: <1270584720.3518.51.camel@localhost>
References: <4BBB7FCF.30903@jcea.es> <1270584720.3518.51.camel@localhost>
Message-ID: <4BBB9D87.3020206@jcea.es>

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

On 04/06/2010 10:12 PM, Antoine Pitrou wrote:
> 
>> My original plan was to delay integration of pybsddb 5.x.x for 2.7.1
>> release
> 
> Bugfix releases are only for bug fixes, by definition. 2.7.1 shouldn't
> receive such a change.

In the past 2.6 received a small patch to be able to compile against BDB
4.8. There are other precedents.

> Why should it be "transparent"? Are you so confident that it won't bring
> any new problems? Given that we are talking about a new major version
> number, this sounds a bit optimistic.

pybsddb 5.0.0 compiles against BDB 5.0.x, but it doesn' support any new
feature. The diff is pretty small, and the testsuite is very extensive.
I am pretty confident.

- -- 
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.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQCVAwUBS7udh5lgi5GaxT1NAQIbDgP/YYgQSmlme8NN2dI1mO37yEJRYMP4fBCw
UvowTILx6WTwEPKPCwCry33ZN+71uIxu51W0411LEhwFxnEFCM4vQYlzkZL9Y/Ym
HZuEJ2xtXj7sod6mz15Qgl3C2sv3ZfL5F3V0wio0fpdaRc4H8sAc/VD0Vzixhl9g
NWKGfS/y0Wo=
=KopF
-----END PGP SIGNATURE-----

From greg at krypto.org  Tue Apr  6 23:43:39 2010
From: greg at krypto.org (Gregory P. Smith)
Date: Tue, 6 Apr 2010 14:43:39 -0700
Subject: [python-committers] pybsddb 5.0.0 integration and 2.7beta1
	schedule
In-Reply-To: <4BBB7FCF.30903@jcea.es>
References: <4BBB7FCF.30903@jcea.es>
Message-ID: <s2n52dc1c821004061443p119d52c2ya92b46ac16c0038d@mail.gmail.com>

On Tue, Apr 6, 2010 at 11:39 AM, Jesus Cea <jcea at jcea.es> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Oracle just released Berkeley DB 5.0.21, with features like SQLite fa?ade.
>
> I am now testing pybsddb 5.0.0, that supports BDB 5.0.x.
>
> My original plan was to delay integration of pybsddb 5.x.x for 2.7.1
> release, but Larry Hastings has a (sensible) request to migrate pybsddb
> from CObject to Capsule for 2.7.0. Current pybsddb 5.0.0 already
> contains that change.

After 2.7.0 is released we can't make any API change like the CObject
to Capsule migration.  I'd go ahead and get that in (if not for beta1,
make sure it is in before beta2).

Tiny tweaks to support compiling against a new BerkeleyDB version that
has the typical minor changes to their API has been done in the past
on .1 or .2 releases as it makes that version of Python last longer as
far as what external libraries it can link against.  I wouldn't object
to that, though I really don't expect there is high demand for that
anymore.

> I am reluctant to integrate the code change before beta1, because
> although it should be transparent I don't want to risk a red buildbot,
> even for 20 minutes, so close to beta1. Integrating it between beta1 and
> beta2 would be riskless, but it would break API compatibility (because
> the CObject->Capsule) change.
>
> I don't know how many people depend of the pybsddb C api, although I
> think that very little.

agreed, probably not many.

>
> What should I do?. When is the beta1 window closed?
>
> PS: I would need a couple of hours for integration, but beware timezone!
> (Spain :).
>

From martin at v.loewis.de  Wed Apr  7 00:54:02 2010
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed, 07 Apr 2010 00:54:02 +0200
Subject: [python-committers] pybsddb 5.0.0 integration and
	2.7beta1	schedule
In-Reply-To: <4BBB9D87.3020206@jcea.es>
References: <4BBB7FCF.30903@jcea.es> <1270584720.3518.51.camel@localhost>
	<4BBB9D87.3020206@jcea.es>
Message-ID: <4BBBBB8A.2050607@v.loewis.de>

Jesus Cea wrote:
> On 04/06/2010 10:12 PM, Antoine Pitrou wrote:
>>> My original plan was to delay integration of pybsddb 5.x.x for 2.7.1
>>> release
>> Bugfix releases are only for bug fixes, by definition. 2.7.1 shouldn't
>> receive such a change.
> 
> In the past 2.6 received a small patch to be able to compile against BDB
> 4.8. There are other precedents.

That would be different, though. Making it work with newer versions of
external libraries does not change the feature set of the module itself,
and may count as a bug fix because it keeps Python compilable on systems
which have the newer library installed.

A new major release of a module probably has new features, which can't
be added in a bug fix release.

>> Why should it be "transparent"? Are you so confident that it won't bring
>> any new problems? Given that we are talking about a new major version
>> number, this sounds a bit optimistic.
> 
> pybsddb 5.0.0 compiles against BDB 5.0.x, but it doesn' support any new
> feature. The diff is pretty small, and the testsuite is very extensive.
> I am pretty confident.

Still, I'm skeptical whether it should be added to 2.7 this late. The
original release date for rc1 was last Saturday, so any new feature
proposed now should be considered as being past the deadline.

Regards,
Martin


From benjamin at python.org  Wed Apr  7 03:09:52 2010
From: benjamin at python.org (Benjamin Peterson)
Date: Tue, 6 Apr 2010 20:09:52 -0500
Subject: [python-committers] [Python-Dev] stabilizing for a release
In-Reply-To: <4BBBC908.90400@v.loewis.de>
References: <m2r1afaf6161004061609zdec59d2buab021f1144b83ec6@mail.gmail.com>
	<4BBBC908.90400@v.loewis.de>
Message-ID: <n2s1afaf6161004061809xea446150r2288b59536a1d1da@mail.gmail.com>

Let's do it. Please no commits to the trunk which are not aimed at
fixing the current buildbot failures. Thank you!

2010/4/6 "Martin v. L?wis" <martin at v.loewis.de>:
> Benjamin Peterson wrote:
>> I propose that we freeze the trunk except for fixes for the buildbots. Thoughts?
>
> Freezing sounds fine with me.
>
> Martin
>



-- 
Regards,
Benjamin

From jcea at jcea.es  Wed Apr  7 03:34:35 2010
From: jcea at jcea.es (Jesus Cea)
Date: Wed, 07 Apr 2010 03:34:35 +0200
Subject: [python-committers] pybsddb 5.0.0 integration
	and	2.7beta1	schedule
In-Reply-To: <4BBBBB8A.2050607@v.loewis.de>
References: <4BBB7FCF.30903@jcea.es>
	<1270584720.3518.51.camel@localhost>	<4BBB9D87.3020206@jcea.es>
	<4BBBBB8A.2050607@v.loewis.de>
Message-ID: <4BBBE12B.1030304@jcea.es>

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

On 04/07/2010 12:54 AM, "Martin v. L?wis" wrote:
> Still, I'm skeptical whether it should be added to 2.7 this late. The
> original release date for rc1 was last Saturday, so any new feature
> proposed now should be considered as being past the deadline.

I agree, and that is the reason I am asking this in the list.

I still think pybsddb 5.0.0 should be in python 2.7.0. My doubt is about
integrating before beta1 or between beta1 and beta2. This is important
because pybsddb 5.0.0 breaks API binary compatibility for those poor
souls that uses the C API exported by it. Probably only relevant to
Oracle Berkeley DB XML team :-), the only people I know that uses it.

If pybsddb 5.0.0 is not integrated, there is still the issue of
CObject->Capsule change.

I just read the message from Benjamin Paterson about the trunk freezing.
That delays the decision until after beta1 :).

Benjamin, as the release manager, what do you think?. The options are:

1. Ships 2.7.0 with current pybsddb code.  The CObject deprecation is
currently silenced explictly.

2. Ships 2.7.0 with current pybssdb code + Capsule support. Current
proposed patch is faulty, but solving it should be trivial. With Beta1
window closed, this will break C API compatibility in beta2... unless
CObject routines can read Capsules, something that the original patch
author says they do. I have not checked it.

3. Ships 2.7.0 with pybsddb 5.0.0. It is a low risk option, I promise.
The only issue is that C API could change between beta1 and beta2. Not
that anybody would use that C API, actually.

I vote for the third option. The capsule patch author Larry Hastings
would like 2. The easy path ("do nothing") is 1.

PS: If we go for 1 or 2, if in 2.7.1 we want to support Berkeley DB
5.0.x (already released a week ago), we must break API anyway, because
some constants have been renamed, and some defaults have been inverted.

- -- 
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.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQCVAwUBS7vhK5lgi5GaxT1NAQJmVwQAlJ/uV8uY+lUe1wEVzAOofotry91/7CML
Ckf6Qvcss3JMDFDSZpVsNPiKPtodz5g0k5ws1nG6sdLEJpNz4PZXRYWI1E0lrlF9
a9D2gWalmpVRfimowxEM7aUy03rB2FGYvAYziuEkKOfYGddazZmnzU/Y9ebSphkB
oJg0kxdCxDU=
=xhXn
-----END PGP SIGNATURE-----

From martin at v.loewis.de  Wed Apr  7 04:13:16 2010
From: martin at v.loewis.de (=?ISO-8859-15?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed, 07 Apr 2010 04:13:16 +0200
Subject: [python-committers] pybsddb 5.0.0
	integration	and	2.7beta1	schedule
In-Reply-To: <4BBBE12B.1030304@jcea.es>
References: <4BBB7FCF.30903@jcea.es>	<1270584720.3518.51.camel@localhost>	<4BBB9D87.3020206@jcea.es>	<4BBBBB8A.2050607@v.loewis.de>
	<4BBBE12B.1030304@jcea.es>
Message-ID: <4BBBEA3C.1020700@v.loewis.de>

> 1. Ships 2.7.0 with current pybsddb code.  The CObject deprecation is
> currently silenced explictly.

This is what I recommend to do. CObject should not be deprecated for
2.x, so bsddb using it is just fine - no need for change.

Regards,
Martin

From fuzzyman at voidspace.org.uk  Wed Apr  7 13:54:51 2010
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Wed, 07 Apr 2010 12:54:51 +0100
Subject: [python-committers] [Python-Dev] stabilizing for a release
In-Reply-To: <s2rd34314101004070330ifd914c14ub3a915ae883d776f@mail.gmail.com>
References: <m2r1afaf6161004061609zdec59d2buab021f1144b83ec6@mail.gmail.com>	<4BBBC908.90400@v.loewis.de>	<n2s1afaf6161004061809xea446150r2288b59536a1d1da@mail.gmail.com>
	<s2rd34314101004070330ifd914c14ub3a915ae883d776f@mail.gmail.com>
Message-ID: <4BBC728B.1070808@voidspace.org.uk>

On 07/04/2010 11:30, anatoly techtonik wrote:
> There is still a serious regression in zipfile module:
> http://bugs.python.org/issue6090
>
> And I would really like to see my issue with difflib tabs committed: =/
> http://bugs.python.org/issue7585
>
>    
The zipfile issue looks like it could be fixed for beta 2. Not so sure 
about the difflib one.

Michael

-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog

READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (?BOGUS AGREEMENTS?) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.



From rdmurray at bitdance.com  Wed Apr  7 20:52:00 2010
From: rdmurray at bitdance.com (R. David Murray)
Date: Wed, 07 Apr 2010 14:52:00 -0400
Subject: [python-committers] [Python-Dev] stabilizing for a release
In-Reply-To: <4BBC728B.1070808@voidspace.org.uk>
References: <m2r1afaf6161004061609zdec59d2buab021f1144b83ec6@mail.gmail.com>
	<4BBBC908.90400@v.loewis.de>
	<n2s1afaf6161004061809xea446150r2288b59536a1d1da@mail.gmail.com>
	<s2rd34314101004070330ifd914c14ub3a915ae883d776f@mail.gmail.com>
	<4BBC728B.1070808@voidspace.org.uk>
Message-ID: <20100407185200.5A3121BC343@kimball.webabinitio.net>

On Wed, 07 Apr 2010 12:54:51 +0100, Michael Foord <fuzzyman at voidspace.org.uk> wrote:
>On 07/04/2010 11:30, anatoly techtonik wrote:
>> There is still a serious regression in zipfile module:
>> http://bugs.python.org/issue6090
>>
>> And I would really like to see my issue with difflib tabs committed: =/
>> http://bugs.python.org/issue7585
>>
>>
>The zipfile issue looks like it could be fixed for beta 2. Not so sure
>about the difflib one.

As Antoine pointed out, 7585 is actually a bug fix (making difflib follow
the unified diff 'standard', as it was originally specified to do).
So unless Benjamin objects I plan to commit it after the freeze.

--David

From benjamin at python.org  Wed Apr  7 22:53:38 2010
From: benjamin at python.org (Benjamin Peterson)
Date: Wed, 7 Apr 2010 15:53:38 -0500
Subject: [python-committers] pybsddb 5.0.0 integration and 2.7beta1
	schedule
In-Reply-To: <4BBBEA3C.1020700@v.loewis.de>
References: <4BBB7FCF.30903@jcea.es> <1270584720.3518.51.camel@localhost>
	<4BBB9D87.3020206@jcea.es> <4BBBBB8A.2050607@v.loewis.de>
	<4BBBE12B.1030304@jcea.es> <4BBBEA3C.1020700@v.loewis.de>
Message-ID: <l2u1afaf6161004071353x52605d50k2032e91578201e5f@mail.gmail.com>

2010/4/6 "Martin v. L?wis" <martin at v.loewis.de>:
>> 1. Ships 2.7.0 with current pybsddb code. ?The CObject deprecation is
>> currently silenced explictly.
>
> This is what I recommend to do. CObject should not be deprecated for
> 2.x, so bsddb using it is just fine - no need for change.

I think this option is best, too.



-- 
Regards,
Benjamin

From benjamin at python.org  Sat Apr 10 18:21:00 2010
From: benjamin at python.org (Benjamin Peterson)
Date: Sat, 10 Apr 2010 11:21:00 -0500
Subject: [python-committers] trunk now completely frozen
Message-ID: <i2u1afaf6161004100921zdae99c4crade894a2b71b3ce1@mail.gmail.com>

Time to release the first beta.

-- 
Regards,
Benjamin

From benjamin at python.org  Sat Apr 10 20:52:51 2010
From: benjamin at python.org (Benjamin Peterson)
Date: Sat, 10 Apr 2010 13:52:51 -0500
Subject: [python-committers] trunk unfrozen
Message-ID: <m2x1afaf6161004101152o16d1bdc2se719a0b531d59a41@mail.gmail.com>

Commit away! I look forward to seeing more green buildbots for the next beta.

-- 
Regards,
Benjamin

From ziade.tarek at gmail.com  Mon Apr 12 09:35:42 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Mon, 12 Apr 2010 09:35:42 +0200
Subject: [python-committers] py3k vs trunk branches
Message-ID: <n2m94bdd2611004120035gcec1eb27tbee56882dc15cce4@mail.gmail.com>

Hello,

I couldn't find anything relevant on this topic in the archives so.. :

Since the 2.x line is now feature frozen (since 2.7 is the last 2.x
release and we have reached beta), most new developments will start in
the py3k branch.
I was wondering if it wouldn't make sense to rename the current trunk
to /py26 and  /py3k to /trunk.

Although I am not sure if this is relevant with the work done on mercurial side.

Regards
Tarek

-- 
Tarek Ziad? | http://ziade.org

From dirkjan at ochtman.nl  Mon Apr 12 09:39:21 2010
From: dirkjan at ochtman.nl (Dirkjan Ochtman)
Date: Mon, 12 Apr 2010 09:39:21 +0200
Subject: [python-committers] py3k vs trunk branches
In-Reply-To: <n2m94bdd2611004120035gcec1eb27tbee56882dc15cce4@mail.gmail.com>
References: <n2m94bdd2611004120035gcec1eb27tbee56882dc15cce4@mail.gmail.com>
Message-ID: <h2hea2499da1004120039odbc71357w4d28af98b974cc50@mail.gmail.com>

On Mon, Apr 12, 2010 at 09:35, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
> Since the 2.x line is now feature frozen (since 2.7 is the last 2.x
> release and we have reached beta), most new developments will start in
> the py3k branch.
> I was wondering if it wouldn't make sense to rename the current trunk
> to /py26 and ?/py3k to /trunk.
>
> Although I am not sure if this is relevant with the work done on mercurial side.

Yeah, I'd prefer to keep it like this for now.

Cheers,

Dirkjan

From brett at python.org  Mon Apr 12 23:34:06 2010
From: brett at python.org (Brett Cannon)
Date: Mon, 12 Apr 2010 14:34:06 -0700
Subject: [python-committers] py3k vs trunk branches
In-Reply-To: <h2hea2499da1004120039odbc71357w4d28af98b974cc50@mail.gmail.com>
References: <n2m94bdd2611004120035gcec1eb27tbee56882dc15cce4@mail.gmail.com> 
	<h2hea2499da1004120039odbc71357w4d28af98b974cc50@mail.gmail.com>
Message-ID: <y2nbbaeab101004121434v1c0a6d5ahc2cecb20200f53fd@mail.gmail.com>

On Mon, Apr 12, 2010 at 00:39, Dirkjan Ochtman <dirkjan at ochtman.nl> wrote:

> On Mon, Apr 12, 2010 at 09:35, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
> > Since the 2.x line is now feature frozen (since 2.7 is the last 2.x
> > release and we have reached beta), most new developments will start in
> > the py3k branch.
> > I was wondering if it wouldn't make sense to rename the current trunk
> > to /py26 and  /py3k to /trunk.
> >
> > Although I am not sure if this is relevant with the work done on
> mercurial side.
>
> Yeah, I'd prefer to keep it like this for now.
>
>
Ditto. Since development will eventually switch there is no need to
complicate the svn stuff and bust existing checkouts by changing the names
now. Better to make any changes when we make the svn/hg switch.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20100412/951f4112/attachment.html>

From rdmurray at bitdance.com  Thu Apr 15 21:43:26 2010
From: rdmurray at bitdance.com (R. David Murray)
Date: Thu, 15 Apr 2010 15:43:26 -0400
Subject: [python-committers] Proposing Giampaolo Rodola' for commit access
Message-ID: <20100415194326.7E3061FF8F0@kimball.webabinitio.net>

I would like to propose Giampaolo Rodola' as a committer.  Giampaolo
has been around the community for several years, has made valuable
contributions on the tracker, particularly in the areas of ftp, asyncore,
and network services in general (he is the principle author of pyftpdlib),
and has had a number of patches committed, including the new FTPS support
in ftplib.  I'm willing to mentor his commits while he gets up to speed
with our processes.

(Frankly, I was surprised to discover that he wasn't a committer
when he inquired about being put in maintainers.rst as an expert for
ftplib.)

--
R. David Murray                                      www.bitdance.com

From trent at snakebite.org  Thu Apr 15 22:30:50 2010
From: trent at snakebite.org (Trent Nelson)
Date: Thu, 15 Apr 2010 13:30:50 -0700
Subject: [python-committers] Proposing Giampaolo Rodola' for commit
 access
In-Reply-To: <20100415194326.7E3061FF8F0@kimball.webabinitio.net>
References: <20100415194326.7E3061FF8F0@kimball.webabinitio.net>
Message-ID: <0A70F247-6518-4E19-B5D8-5B1C94A37D14@snakebite.org>


On 15 Apr 2010, at 20:43, R. David Murray wrote:

> I would like to propose Giampaolo Rodola' as a committer.  Giampaolo
> has been around the community for several years, has made valuable
> contributions on the tracker, particularly in the areas of ftp, asyncore,
> and network services in general (he is the principle author of pyftpdlib),
> and has had a number of patches committed, including the new FTPS support
> in ftplib.  I'm willing to mentor his commits while he gets up to speed
> with our processes.
> 
> (Frankly, I was surprised to discover that he wasn't a committer
> when he inquired about being put in maintainers.rst as an expert for
> ftplib.)
> 

+1


From solipsis at pitrou.net  Fri Apr 16 17:12:45 2010
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Fri, 16 Apr 2010 17:12:45 +0200
Subject: [python-committers] Proposing Giampaolo Rodola' for commit
 access
In-Reply-To: <20100415194326.7E3061FF8F0@kimball.webabinitio.net>
References: <20100415194326.7E3061FF8F0@kimball.webabinitio.net>
Message-ID: <1271430765.3412.22.camel@localhost>

Le jeudi 15 avril 2010 ? 15:43 -0400, R. David Murray a ?crit :
> I would like to propose Giampaolo Rodola' as a committer.  Giampaolo
> has been around the community for several years, has made valuable
> contributions on the tracker, particularly in the areas of ftp, asyncore,
> and network services in general (he is the principle author of pyftpdlib),
> and has had a number of patches committed, including the new FTPS support
> in ftplib.  I'm willing to mentor his commits while he gets up to speed
> with our processes.

Sounds good to me.

cheers

Antoine.



From michael at voidspace.org.uk  Mon Apr 19 20:51:32 2010
From: michael at voidspace.org.uk (Michael Foord)
Date: Mon, 19 Apr 2010 20:51:32 +0200
Subject: [python-committers] Proposing Tim Golden as a Committer
Message-ID: <4BCCA634.9000009@voidspace.org.uk>

Hello all,

I would like to propose Tim Golden as a Python committer. He has been 
involved in Python for many years, is a capable Windows guy, and has 
submitted many patches / documentation fixes - particularly for Windows 
issues.

He may need a mentor, but here are many issues that he has contributed 
patches for:

     * Tests for test.support.unlink on windows) 
http://bugs.python.org/issue7443 (open)
     * mmap patch here: http://bugs.python.org/issue2733 (open)
     * subprocess patch here: http://bugs.python.org/issue2304 (open)
     * bdb documentation http://bugs.python.org/issue1136 (committed)
     * print media stylesheet for Sphinx docs 
http://bugs.python.org/issue1555 (committed)
     * distutil.test_util issue http://bugs.python.org/issue5472 (committed)
     * multiprocessing build fix http://bugs.python.org/issue3050 
(committed)
     * Windows msi missing file http://bugs.python.org/issue5470 (committed)
     * msi.py copies non-existent files http://bugs.python.org/issue5721 
(committed)
     * with lock fails on multiprocessing 
http://bugs.python.org/issue5261 (committed)
     * _winreg remaining in test_winsound 
http://bugs.python.org/issue8385 (committed)

I skipped a bunch of further committed docs patches. I've known Tim for 
a while (although not well) and consider him an easy to get on with and 
straightforward guy. Having contributed patches for so long I'm sure he 
knows our processes well.

At the very least we should grant Tim tracker privileges as he 
frequently responds to issues.

All the best,

Michael Foord

-- 
http://www.ironpythoninaction.com/


From martin at v.loewis.de  Mon Apr 19 22:30:22 2010
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon, 19 Apr 2010 22:30:22 +0200
Subject: [python-committers] Proposing Tim Golden as a Committer
In-Reply-To: <4BCCA634.9000009@voidspace.org.uk>
References: <4BCCA634.9000009@voidspace.org.uk>
Message-ID: <4BCCBD5E.4070100@v.loewis.de>

> I would like to propose Tim Golden as a Python committer.

Anybody supporting this addition?

> At the very least we should grant Tim tracker privileges as he
> frequently responds to issues.

Done!

Martin

From michael at voidspace.org.uk  Mon Apr 19 22:43:05 2010
From: michael at voidspace.org.uk (Michael Foord)
Date: Mon, 19 Apr 2010 22:43:05 +0200
Subject: [python-committers] Proposing Tim Golden as a Committer
In-Reply-To: <4BCCBD5E.4070100@v.loewis.de>
References: <4BCCA634.9000009@voidspace.org.uk> <4BCCBD5E.4070100@v.loewis.de>
Message-ID: <4BCCC059.9040501@voidspace.org.uk>

On 19/04/2010 22:30, "Martin v. L?wis" wrote:
>> I would like to propose Tim Golden as a Python committer.
>>      
> Anybody supporting this addition?
>
>    

I'd be happy to mentor Tim through his early commits - commit procedure, 
keeping stuff on the tracker, reviewing standard library patches etc. I 
honestly don't think he will need much mentoring though.

All the best,

Michael


>> At the very least we should grant Tim tracker privileges as he
>> frequently responds to issues.
>>      
> Done!
>
> Martin
>    


-- 
http://www.ironpythoninaction.com/


From brian.curtin at gmail.com  Mon Apr 19 22:49:23 2010
From: brian.curtin at gmail.com (Brian Curtin)
Date: Mon, 19 Apr 2010 15:49:23 -0500
Subject: [python-committers] Proposing Tim Golden as a Committer
In-Reply-To: <4BCCBD5E.4070100@v.loewis.de>
References: <4BCCA634.9000009@voidspace.org.uk> <4BCCBD5E.4070100@v.loewis.de>
Message-ID: <i2vcf9f31f21004191349ze6579c5ewc33223e2ec8b0f42@mail.gmail.com>

On Mon, Apr 19, 2010 at 15:30, "Martin v. L?wis" <martin at v.loewis.de> wrote:

> > I would like to propose Tim Golden as a Python committer.
>
> Anybody supporting this addition?
>
> > At the very least we should grant Tim tracker privileges as he
> > frequently responds to issues.
>
> Done!
>
> Martin


+1. Tim seems to be a pretty sharp Windows guy (especially witnessed in his
WMI project), and his contributions look good.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20100419/c813f452/attachment.html>

From mhammond at skippinet.com.au  Tue Apr 20 01:07:15 2010
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Tue, 20 Apr 2010 09:07:15 +1000
Subject: [python-committers] Proposing Tim Golden as a Committer
In-Reply-To: <4BCCA634.9000009@voidspace.org.uk>
References: <4BCCA634.9000009@voidspace.org.uk>
Message-ID: <4BCCE223.1000104@skippinet.com.au>

On 20/04/2010 4:51 AM, Michael Foord wrote:
> Hello all,
>
> I would like to propose Tim Golden as a Python committer. He has been
> involved in Python for many years, is a capable Windows guy, and has
> submitted many patches / documentation fixes - particularly for Windows
> issues.

+1 - he has been an excellent contributor of code and wisdom to pywin32 
and its users...

Cheers,

Mark

From greg at krypto.org  Tue Apr 20 07:17:41 2010
From: greg at krypto.org (Gregory P. Smith)
Date: Mon, 19 Apr 2010 22:17:41 -0700
Subject: [python-committers] Proposing Tim Golden as a Committer
In-Reply-To: <4BCCE223.1000104@skippinet.com.au>
References: <4BCCA634.9000009@voidspace.org.uk>
	<4BCCE223.1000104@skippinet.com.au>
Message-ID: <n2m52dc1c821004192217xe73f2454z431f5699c49eb077@mail.gmail.com>

On Mon, Apr 19, 2010 at 4:07 PM, Mark Hammond <mhammond at skippinet.com.au> wrote:
> On 20/04/2010 4:51 AM, Michael Foord wrote:
>>
>> Hello all,
>>
>> I would like to propose Tim Golden as a Python committer. He has been
>> involved in Python for many years, is a capable Windows guy, and has
>> submitted many patches / documentation fixes - particularly for Windows
>> issues.
>
> +1 - he has been an excellent contributor of code and wisdom to pywin32 and
> its users...

+1

From g.brandl at gmx.net  Sun Apr 25 19:18:04 2010
From: g.brandl at gmx.net (Georg Brandl)
Date: Sun, 25 Apr 2010 19:18:04 +0200
Subject: [python-committers] Blocking commits to 2.6
Message-ID: <hr1th1$qkv$1@dough.gmane.org>

Hi,

to make my life easier, I'd like to block all unmerged commits in 2.6 that
nobody will merge anyway.  I use ``svnmerge avail --log`` to find out which
commits I have to merge, and with the current number of unmerged commits it
is taking longer and longer.

Does anyone else use svnmerge integration info on the 2.6 branch?  Please
speak up, so that I don't mess up your workflow.

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.


From barry at python.org  Sun Apr 25 19:59:27 2010
From: barry at python.org (Barry Warsaw)
Date: Sun, 25 Apr 2010 13:59:27 -0400
Subject: [python-committers] Blocking commits to 2.6
In-Reply-To: <hr1th1$qkv$1@dough.gmane.org>
References: <hr1th1$qkv$1@dough.gmane.org>
Message-ID: <61B6A396-1C1D-4A0D-A1CC-C55AF5AE0806@python.org>

On Apr 25, 2010, at 1:18 PM, Georg Brandl wrote:

> to make my life easier, I'd like to block all unmerged commits in 2.6 that
> nobody will merge anyway.  I use ``svnmerge avail --log`` to find out which
> commits I have to merge, and with the current number of unmerged commits it
> is taking longer and longer.
> 
> Does anyone else use svnmerge integration info on the 2.6 branch?  Please
> speak up, so that I don't mess up your workflow.

Not me.  I find the whole svnmerge stuff madness anyway. :)

-Barry


From jcea at jcea.es  Mon Apr 26 02:41:19 2010
From: jcea at jcea.es (Jesus Cea)
Date: Mon, 26 Apr 2010 02:41:19 +0200
Subject: [python-committers] Blocking commits to 2.6
In-Reply-To: <61B6A396-1C1D-4A0D-A1CC-C55AF5AE0806@python.org>
References: <hr1th1$qkv$1@dough.gmane.org>
	<61B6A396-1C1D-4A0D-A1CC-C55AF5AE0806@python.org>
Message-ID: <4BD4E12F.2050901@jcea.es>

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

On 25/04/10 19:59, Barry Warsaw wrote:
>> Does anyone else use svnmerge integration info on the 2.6 branch?  Please
>> speak up, so that I don't mess up your workflow.
> 
> Not me.  I find the whole svnmerge stuff madness anyway. :)

Mercurial can not come soon enough :).

- -- 
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.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQCVAwUBS9ThL5lgi5GaxT1NAQKFdAP+Lqs/L9SegnEuZ5GkVMKEoDEWor4lXzGr
eb/DFrNTtLs3LyNBp92Wjb1ewAz/tHo2KWBiRVbYQrRqVgUxB4+o7k4jiPAvu7z+
58blMKAsLDc8DR3OYxtXR+m7iza0tY7tkUa4ETmI1wXquGXGkfffoZ7s8R1Zk5h4
Y7BBSB+5bD0=
=1ar3
-----END PGP SIGNATURE-----

From ncoghlan at gmail.com  Mon Apr 26 03:38:00 2010
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Mon, 26 Apr 2010 11:38:00 +1000
Subject: [python-committers] Blocking commits to 2.6
In-Reply-To: <hr1th1$qkv$1@dough.gmane.org>
References: <hr1th1$qkv$1@dough.gmane.org>
Message-ID: <4BD4EE78.8010804@gmail.com>

Georg Brandl wrote:
> Hi,
> 
> to make my life easier, I'd like to block all unmerged commits in 2.6 that
> nobody will merge anyway.  I use ``svnmerge avail --log`` to find out which
> commits I have to merge, and with the current number of unmerged commits it
> is taking longer and longer.
> 
> Does anyone else use svnmerge integration info on the 2.6 branch?  Please
> speak up, so that I don't mess up your workflow.

I'd say go ahead - if anyone has a particular change that they want to
backport, they can still do it manually (or else unblock it first).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------

From larry at hastings.org  Tue Apr 27 12:23:59 2010
From: larry at hastings.org (Larry Hastings)
Date: Tue, 27 Apr 2010 03:23:59 -0700
Subject: [python-committers] When do we stop automerging from trunk to py3k?
Message-ID: <4BD6BB3F.4020807@hastings.org>



Pardon my general n00bishness, but I crave knowledge.  IIUC currently if 
you have a checkin in trunk that you *don't* want merged into py3k, you 
must svnmerge block it in py3k.  Otherwise it will be automatically 
merged at some point.

My question is: when will we stop doing that?  I assume that as time 
passes trunk and py3k will continue to drift further and further apart.  
My guess is that more checkins are blocked than are allowed through.  So 
when will we stop the automerging?

Or is this question a sign of a more fundamental misunderstanding?

I'm afraid I have to tell you even I really just don't know,


/larry/

From solipsis at pitrou.net  Tue Apr 27 12:38:53 2010
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Tue, 27 Apr 2010 12:38:53 +0200
Subject: [python-committers] When do we stop automerging from trunk to
 py3k?
In-Reply-To: <4BD6BB3F.4020807@hastings.org>
References: <4BD6BB3F.4020807@hastings.org>
Message-ID: <1272364733.3485.4.camel@localhost>

Le mardi 27 avril 2010 ? 03:23 -0700, Larry Hastings a ?crit :
> 
> Pardon my general n00bishness, but I crave knowledge.  IIUC currently if 
> you have a checkin in trunk that you *don't* want merged into py3k, you 
> must svnmerge block it in py3k.  Otherwise it will be automatically 
> merged at some point.

Your U is not C.  Nobody/nothing automerges. On the contrary, it is
highly recommended that you "svnmerge merge" changes yourself if you
want them to be merged (that is, ported).

It is also recommended that you "svnmerge block" changes which you think
shouldn't be ported to py3k. That way, it will leave the merge queue
clean and short (if it has ever been :-)).

Regards

Antoine.



From michael at voidspace.org.uk  Tue Apr 27 12:45:58 2010
From: michael at voidspace.org.uk (Michael Foord)
Date: Tue, 27 Apr 2010 11:45:58 +0100
Subject: [python-committers] When do we stop automerging from trunk to
 py3k?
In-Reply-To: <1272364733.3485.4.camel@localhost>
References: <4BD6BB3F.4020807@hastings.org> <1272364733.3485.4.camel@localhost>
Message-ID: <4BD6C066.80705@voidspace.org.uk>

On 27/04/2010 11:38, Antoine Pitrou wrote:
> Le mardi 27 avril 2010 ? 03:23 -0700, Larry Hastings a ?crit :
>    
>> Pardon my general n00bishness, but I crave knowledge.  IIUC currently if
>> you have a checkin in trunk that you *don't* want merged into py3k, you
>> must svnmerge block it in py3k.  Otherwise it will be automatically
>> merged at some point.
>>      
> Your U is not C.  Nobody/nothing automerges. On the contrary, it is
> highly recommended that you "svnmerge merge" changes yourself if you
> want them to be merged (that is, ported).
>
> It is also recommended that you "svnmerge block" changes which you think
> shouldn't be ported to py3k. That way, it will leave the merge queue
> clean and short (if it has ever been :-)).
>    

Standard library changes are still *largely* amenable to merging.

My guess is that *after* the release of 2.7, and probably also after we 
switch to mercurial, py3k will become the equivalent of trunk. Of course 
once we switch to mercurial the use of svnmerge will stop. Bugfixes may 
still need merging from py3k to 2.7 (and 3.1), but not new features. 
Allegedly merging between branches will be easier with Mercurial anyway...

All the best,

Michael

> Regards
>
> Antoine.
>
>
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> http://mail.python.org/mailman/listinfo/python-committers
>    


-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog

READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (?BOGUS AGREEMENTS?) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20100427/e2fd9c1c/attachment.html>

From chris at simplistix.co.uk  Tue Apr 27 15:01:36 2010
From: chris at simplistix.co.uk (Chris Withers)
Date: Tue, 27 Apr 2010 14:01:36 +0100
Subject: [python-committers] When do we stop automerging from trunk to
 py3k?
In-Reply-To: <4BD6C066.80705@voidspace.org.uk>
References: <4BD6BB3F.4020807@hastings.org> <1272364733.3485.4.camel@localhost>
	<4BD6C066.80705@voidspace.org.uk>
Message-ID: <4BD6E030.10202@simplistix.co.uk>

Michael Foord wrote:
> Allegedly merging between branches will be easier with Mercurial anyway...

I hope an Hg expert can show how this can be done...

In particular, we don't want to pull all changes to 2.7 into 3k, and I 
haven't seen any sane way in Hg to say "just pull this changeset, no 
others"...

cheers,

Chris


From solipsis at pitrou.net  Tue Apr 27 15:05:49 2010
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Tue, 27 Apr 2010 15:05:49 +0200
Subject: [python-committers] When do we stop automerging from trunk to
 py3k?
In-Reply-To: <4BD6E030.10202@simplistix.co.uk>
References: <4BD6BB3F.4020807@hastings.org>
	<1272364733.3485.4.camel@localhost> <4BD6C066.80705@voidspace.org.uk>
	<4BD6E030.10202@simplistix.co.uk>
Message-ID: <1272373549.3485.7.camel@localhost>

Le mardi 27 avril 2010 ? 14:01 +0100, Chris Withers a ?crit :
> Michael Foord wrote:
> > Allegedly merging between branches will be easier with Mercurial anyway...
> 
> I hope an Hg expert can show how this can be done...
> 
> In particular, we don't want to pull all changes to 2.7 into 3k, and I 
> haven't seen any sane way in Hg to say "just pull this changeset, no 
> others"...

Depends what you call "sane". There's the transplant extension, which
aims precisely at managing cherry-picked patches. Otherwise, just "hg
import" of a patch. Both don't seem more sophisticated/automated than
the current workflow.

Regards

Antoine.



From rdmurray at bitdance.com  Tue Apr 27 16:05:11 2010
From: rdmurray at bitdance.com (R. David Murray)
Date: Tue, 27 Apr 2010 10:05:11 -0400
Subject: [python-committers] When do we stop automerging from trunk to
	py3k?
In-Reply-To: <4BD6BB3F.4020807@hastings.org>
References: <4BD6BB3F.4020807@hastings.org>
Message-ID: <20100427140511.704A61FC6D7@kimball.webabinitio.net>

On Tue, 27 Apr 2010 03:23:59 -0700, Larry Hastings <larry at hastings.org> wrote:
> My guess is that more checkins are blocked than are allowed through.  So 
> when will we stop the automerging?

As Antoine said, there is no automerging.  As for the number of commits
that get ported to py3k, it is almost all of them.  Only the ones that
are backports from py3k get blocked, and there shouldn't be any more of
those now that we are in beta for 2.7.  New features only go into py3k
at this point (and should get blocked on the 3.1 branch).  py3k-only
bugs go into py3k and then merged (by hand :) into 3.1.  But most bug
fixes still go into trunk, and are then merged to 2.6, py3k, and 3.1.
So currently almost every commit to trunk should get merged to py3k.
(There are a few exceptions where the bug only exists in the 2.x series,
or where the merge gets done without using svnmerge for one reason or
another.)

--
R. David Murray                                      www.bitdance.com

From martin at v.loewis.de  Tue Apr 27 22:21:53 2010
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 27 Apr 2010 22:21:53 +0200
Subject: [python-committers] When do we stop automerging from trunk to
 py3k?
In-Reply-To: <4BD6BB3F.4020807@hastings.org>
References: <4BD6BB3F.4020807@hastings.org>
Message-ID: <4BD74761.4020202@v.loewis.de>

> Pardon my general n00bishness, but I crave knowledge.  IIUC currently if
> you have a checkin in trunk that you *don't* want merged into py3k, you
> must svnmerge block it in py3k.  Otherwise it will be automatically
> merged at some point.
> 
> My question is: when will we stop doing that?

Nobody has really answered this question, so let me try: After 2.7 is
released (i.e. within two months), the 2.x branch (i.e. the trunk) will
be closed for changes altogether. So merging changes from trunk to the
3.x branch becomes unnecessary, and we can stop doing that (*).

Around the same time, we will also switch to Mercurial, so the point of
using svnmerge and blocking changes becomes irrelevant for that reason,
also.

So in short: in less than two months.

Regards,
Martin

(*) there still might be bug fixes applied to the 2.7 maintenance branch
which also apply to the 3.x branch. I would expect that there won't be
an automatic migration of all changes in either direction, and that,
with Mercurial, migration of selected changes can occur in either
direction. In any case, this will not be about the trunk.

From jcea at jcea.es  Wed Apr 28 04:37:54 2010
From: jcea at jcea.es (Jesus Cea)
Date: Wed, 28 Apr 2010 04:37:54 +0200
Subject: [python-committers] When do we stop automerging from trunk to
 py3k?
In-Reply-To: <4BD6E030.10202@simplistix.co.uk>
References: <4BD6BB3F.4020807@hastings.org>
	<1272364733.3485.4.camel@localhost>	<4BD6C066.80705@voidspace.org.uk>
	<4BD6E030.10202@simplistix.co.uk>
Message-ID: <4BD79F82.5040005@jcea.es>

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

On 27/04/10 15:01, Chris Withers wrote:
> Michael Foord wrote:
>> Allegedly merging between branches will be easier with Mercurial
>> anyway...
> 
> I hope an Hg expert can show how this can be done...
> 
> In particular, we don't want to pull all changes to 2.7 into 3k, and I
> haven't seen any sane way in Hg to say "just pull this changeset, no
> others"...

There are extensions for it.

For instance <http://mercurial.selenic.com/wiki/TransplantExtension>.

Anyway, a possible simple workflow is to write patches for the older
supported python version and merge them in newer versions, adjusted or,
possibly, "backout"ed.

That is, patch 2.7 and "push" those changes to 3.x, undoing the
unnecesary patches with a simple "backout".

This is far more automatic that cherrypicking patches, with the risk of
forgeting some.

I can't wait for HG native use, and I am curious about the exact
workflow we are going to use.

- -- 
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.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQCVAwUBS9efgplgi5GaxT1NAQIT2QP9FCHzsKkBkZyOdkf5Zydnv65YUhEiVFre
tGVMqfuP4XtzLSdGDUHBJYqg1Bw6piuzNtyTOGTvE7J70LfZsdvDOPo7gByKHdXp
KkcrFruvqjN/Ff7ozJsnvT0rmBDUjGEt9PjrpTGUd3yMgWq42CJqe1j/KRiMuRRH
dXz7UXTBBow=
=sO/M
-----END PGP SIGNATURE-----

From solipsis at pitrou.net  Wed Apr 28 12:17:38 2010
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Wed, 28 Apr 2010 12:17:38 +0200
Subject: [python-committers] When do we stop automerging from trunk to
 py3k?
In-Reply-To: <4BD79F82.5040005@jcea.es>
References: <4BD6BB3F.4020807@hastings.org>
	<1272364733.3485.4.camel@localhost>	<4BD6C066.80705@voidspace.org.uk>
	<4BD6E030.10202@simplistix.co.uk>  <4BD79F82.5040005@jcea.es>
Message-ID: <1272449858.3485.5.camel@localhost>

Le mercredi 28 avril 2010 ? 04:37 +0200, Jesus Cea a ?crit :
> That is, patch 2.7 and "push" those changes to 3.x, undoing the
> unnecesary patches with a simple "backout".

Good point. I haven't thought of the possibility of using "hg backout".
However, those bugfixes must also be applied (usually) to 3.1, which
makes the workflow graph a bit uncertain:
(3.1 -> 2.7) and (3.1 -> 3.x)?

Regards

Antoine.



From jcea at jcea.es  Wed Apr 28 19:01:36 2010
From: jcea at jcea.es (Jesus Cea)
Date: Wed, 28 Apr 2010 19:01:36 +0200
Subject: [python-committers] When do we stop automerging from trunk to
 py3k?
In-Reply-To: <1272449858.3485.5.camel@localhost>
References: <4BD6BB3F.4020807@hastings.org>	<1272364733.3485.4.camel@localhost>	<4BD6C066.80705@voidspace.org.uk>	<4BD6E030.10202@simplistix.co.uk>
	<4BD79F82.5040005@jcea.es> <1272449858.3485.5.camel@localhost>
Message-ID: <4BD869F0.40204@jcea.es>

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

On 28/04/10 12:17, Antoine Pitrou wrote:
> Le mercredi 28 avril 2010 ? 04:37 +0200, Jesus Cea a ?crit :
>> That is, patch 2.7 and "push" those changes to 3.x, undoing the
>> unnecesary patches with a simple "backout".
> 
> Good point. I haven't thought of the possibility of using "hg backout".
> However, those bugfixes must also be applied (usually) to 3.1, which
> makes the workflow graph a bit uncertain:
> (3.1 -> 2.7) and (3.1 -> 3.x)?

Yes, I would "push":

2.6 -> 2.7 -> 3.1 -> 3.x

Versions in the right must include patches done for the versions in the
left. Also, versions more in the left change less.

I am not formally proposing this workflow, but it would leverage the
merge excellence of Mercurial.

The bad thing about "backout" is the polution of the repository history.
Another option would be to push the change and do a "null merge", were
we actually "cancel" the change. But that would "lie" in the history and
could require a fake commit in the "tip" to have two heads to merge.

Looking in this way, the "backout" path seems better, because it
documents both "we have considered this patch" as the outcome "but we
don't need it in this 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.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQCVAwUBS9hp8Jlgi5GaxT1NAQLOzAP+KBx0UIrRtXkPBDMujm3L8pEhGzmBFdAF
fIasqcyMMX/Z5ZpNFwIwQ/pcf4vgk8J8fbhV+DUJb4J7dHs8DMf/UZv0Xt/JXl88
IZOC23CwYSTcc3jp69frRdC/KUznmYRWyo5rzJ89R+vl1YDXD5tZPX8djv+6Aoew
L8BxKJ9rUvw=
=KUEr
-----END PGP SIGNATURE-----