From brett at python.org  Sun Aug  3 21:40:13 2008
From: brett at python.org (Brett Cannon)
Date: Sun, 3 Aug 2008 12:40:13 -0700
Subject: [python-committers] Everyone is now subscribed (and two people to
	drop)
Message-ID: <bbaeab100808031240l243932b6s636a34eefa56b44e@mail.gmail.com>

I have now finished subscribing people to this list (and allowing
mail-archive.com and gmane.org to archive the list).

Roy Smith and Jackilyn Hoxworth I found out either want to give up
their commit privileges or they were temporary for GSoC. So whomever
knows how to remove commit privileges, please remove the two of them.

-Brett

From brett at python.org  Sun Aug  3 21:51:06 2008
From: brett at python.org (Brett Cannon)
Date: Sun, 3 Aug 2008 12:51:06 -0700
Subject: [python-committers] Revoking Matt Fleming's commit privileges
Message-ID: <bbaeab100808031251o779bfa3fx864a8d3bac162db1@mail.gmail.com>

Just got this email from Matt.


---------- Forwarded message ----------
From: Matt Fleming <mattjfleming at googlemail.com>
Date: Sun, Aug 3, 2008 at 12:47 PM
Subject: Re: [python-committers] Everyone is now subscribed (and two
people to drop)
To: Brett Cannon <brett at python.org>

Hi Brett,

would it be possible to get my commit privileges revoked, please? I
was given commit privileges as part of my GSoC work in 2006 but no
longer require them.

Thanks

From brett at python.org  Mon Aug  4 00:19:30 2008
From: brett at python.org (Brett Cannon)
Date: Sun, 3 Aug 2008 15:19:30 -0700
Subject: [python-committers] Revoking Richard Emslie's privs
Message-ID: <bbaeab100808031519p589eb723u7fde72cf07f00794@mail.gmail.com>

Another person requesting their privs be removed.


---------- Forwarded message ----------
From: Richard Emslie <richardemslie at gmail.com>
Date: Sun, Aug 3, 2008 at 12:57 PM
Subject: Re: [python-committers] Revoking Matt Fleming's commit privileges
To: Brett Cannon <brett at python.org>



Can I revoke mine also please.  Was added as part of NFS sprint, but
have never considered myself a core python developer.
Thanks,
Richard Emslie

Brett Cannon wrote:
>
> Just got this email from Matt.
>
>
> ---------- Forwarded message ----------
> From: Matt Fleming <mattjfleming at googlemail.com>
> Date: Sun, Aug 3, 2008 at 12:47 PM
> Subject: Re: [python-committers] Everyone is now subscribed (and two
> people to drop)
> To: Brett Cannon <brett at python.org>
>
> Hi Brett,
>
> would it be possible to get my commit privileges revoked, please? I
> was given commit privileges as part of my GSoC work in 2006 but no
> longer require them.
>
> Thanks
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> http://mail.python.org/mailman/listinfo/python-committers
>

From georg at python.org  Mon Aug  4 02:28:43 2008
From: georg at python.org (Georg Brandl)
Date: Mon, 04 Aug 2008 00:28:43 +0000
Subject: [python-committers] Revoking Richard Emslie's privs
In-Reply-To: <bbaeab100808031519p589eb723u7fde72cf07f00794@mail.gmail.com>
References: <bbaeab100808031519p589eb723u7fde72cf07f00794@mail.gmail.com>
Message-ID: <48964D3B.8090007@python.org>

Brett Cannon schrieb:
> Another person requesting their privs be removed.

I've now removed all four keys in question from the repository.

Georg

From tnelson at onresolve.com  Mon Aug 11 21:27:36 2008
From: tnelson at onresolve.com (Trent Nelson)
Date: Mon, 11 Aug 2008 20:27:36 +0100
Subject: [python-committers] Nominate Hirokazu Yamamoto (oceancity) for
	commit privs.
Message-ID: <6167796BFEB5D0438720AC212E89A6B0078F4D64@exchange.onresolve.com>


What do people think about making Hirokazu Yamamoto a committer?  I rarely see any mailing list posts from him, but he sure makes up for it in terms of patches submitted to the issue tracker.  As far as I can tell (I've noticed his regular involvement via patches and whatnot for well over a year), he's a pretty switched on guy with a lot of Windows experience -- every time trunk fails to build with vc6/7/8, for example, he's got patches lined up.


        Trent.

From jnoller at gmail.com  Mon Aug 11 21:38:05 2008
From: jnoller at gmail.com (Jesse Noller)
Date: Mon, 11 Aug 2008 15:38:05 -0400
Subject: [python-committers] Nominate Hirokazu Yamamoto (oceancity) for
	commit privs.
In-Reply-To: <6167796BFEB5D0438720AC212E89A6B0078F4D64@exchange.onresolve.com>
References: <6167796BFEB5D0438720AC212E89A6B0078F4D64@exchange.onresolve.com>
Message-ID: <4222a8490808111238p49c57e6buc806b1f725812520@mail.gmail.com>

Although I'm new, I would be +1 - more windows experience with a
willingness to provide patches is something I feel we need.

On Mon, Aug 11, 2008 at 3:27 PM, Trent Nelson <tnelson at onresolve.com> wrote:
>
> What do people think about making Hirokazu Yamamoto a committer?  I rarely see any mailing list posts from him, but he sure makes up for it in terms of patches submitted to the issue tracker.  As far as I can tell (I've noticed his regular involvement via patches and whatnot for well over a year), he's a pretty switched on guy with a lot of Windows experience -- every time trunk fails to build with vc6/7/8, for example, he's got patches lined up.
>
>
>        Trent.
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> http://mail.python.org/mailman/listinfo/python-committers
>

From martin at v.loewis.de  Mon Aug 11 21:56:13 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon, 11 Aug 2008 21:56:13 +0200
Subject: [python-committers] Nominate Hirokazu Yamamoto (oceancity) for
 commit privs.
In-Reply-To: <6167796BFEB5D0438720AC212E89A6B0078F4D64@exchange.onresolve.com>
References: <6167796BFEB5D0438720AC212E89A6B0078F4D64@exchange.onresolve.com>
Message-ID: <48A0995D.6010902@v.loewis.de>

Trent Nelson wrote:
> What do people think about making Hirokazu Yamamoto a committer?  I
> rarely see any mailing list posts from him, but he sure makes up for
> it in terms of patches submitted to the issue tracker.  As far as I
> can tell (I've noticed his regular involvement via patches and
> whatnot for well over a year), he's a pretty switched on guy with a
> lot of Windows experience -- every time trunk fails to build with
> vc6/7/8, for example, he's got patches lined up.

I'm in favor. Trent, do you want to approach him?

We need a real name, latin spelling, first.last (although he might
prefer last.first instead - I suppose Yamamoto is the family name),
plus an ssh key.

Regards,
Martin

From lists at cheimes.de  Mon Aug 11 21:42:47 2008
From: lists at cheimes.de (Christian Heimes)
Date: Mon, 11 Aug 2008 21:42:47 +0200
Subject: [python-committers] Nominate Hirokazu Yamamoto (oceancity) for
 commit privs.
In-Reply-To: <6167796BFEB5D0438720AC212E89A6B0078F4D64@exchange.onresolve.com>
References: <6167796BFEB5D0438720AC212E89A6B0078F4D64@exchange.onresolve.com>
Message-ID: <48A09637.2090102@cheimes.de>

Trent Nelson wrote:
> What do people think about making Hirokazu Yamamoto a committer?  I rarely see any mailing list posts from him, but he sure makes up for it in terms of patches submitted to the issue tracker.  As far as I can tell (I've noticed his regular involvement via patches and whatnot for well over a year), he's a pretty switched on guy with a lot of Windows experience -- every time trunk fails to build with vc6/7/8, for example, he's got patches lined up.

+1 from me

I like to nominate Hirokazu as maintainer of the VC 6 to VS 8 (2005) 
build directories. He is pretty much the only tester of the VC 6 and VS 
7 build systems - and one of the few that care about the old versions of 
MS compilers, too.

Christian

From asmodai at in-nomine.org  Mon Aug 11 22:15:34 2008
From: asmodai at in-nomine.org (Jeroen Ruigrok van der Werven)
Date: Mon, 11 Aug 2008 22:15:34 +0200
Subject: [python-committers] Nominate Hirokazu Yamamoto (oceancity)
	for	commit privs.
In-Reply-To: <48A0995D.6010902@v.loewis.de>
References: <6167796BFEB5D0438720AC212E89A6B0078F4D64@exchange.onresolve.com>
	<48A0995D.6010902@v.loewis.de>
Message-ID: <20080811201534.GL57679@nexus.in-nomine.org>

-On [20080811 21:56], "Martin v. L?wis" (martin at v.loewis.de) wrote:
>We need a real name, latin spelling, first.last (although he might
>prefer last.first instead - I suppose Yamamoto is the family name),
>plus an ssh key.

Yes, ??(yamamoto) is the family name.

-- 
Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai
????? ?????? ??? ?? ??????
http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B
Don't always think in a straight line...

From barry at python.org  Tue Aug 12 01:02:15 2008
From: barry at python.org (Barry Warsaw)
Date: Mon, 11 Aug 2008 19:02:15 -0400
Subject: [python-committers] [Python-Dev] next beta
In-Reply-To: <2F883F29-DAD8-4D4D-948D-DDAD872EB2A4@python.org>
References: <4838EA2D.7060402@jcea.es>
	<319e029f0806020752necf5acer9866c158ce9ac286@mail.gmail.com>
	<488150A5.8050804@jcea.es>
	<B98D6CBA-6D19-482F-B11D-1FF60B77F17A@barrys-emacs.org>
	<488451AB.50406@jcea.es> <g61jt8$hag$2@ger.gmane.org>
	<4884581F.8010201@jcea.es>
	<bbaeab100807211116g4df70dc1o81b1075a88282c93@mail.gmail.com>
	<1BDCADF2-F6EE-4824-80BF-68CB1760CA7B@python.org>
	<loom.20080811T095014-204@post.gmane.org>
	<2F883F29-DAD8-4D4D-948D-DDAD872EB2A4@python.org>
Message-ID: <6D041763-67AC-4213-AF2B-4AFBB991C699@python.org>

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

On Aug 11, 2008, at 8:27 AM, Barry Warsaw wrote:

> Ah darn, that's a typo in the PEP.  I definitely meant August 13, as  
> the Google calendar shows.
>
> Do we think we can be ready for beta3 this Wednesday?  If not, I'd  
> rather stick to a weekday release and do it on Wednesday August  
> 20th.  Let me know what you think.

It sounds like Wednesday August 13th will not be feasible, so we'll do  
beta 3 on Wednesday August 20th.  I've updated both the PEP and the  
Google Calendar.

Thanks,
- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSKDE+XEjvBPtnXfVAQIATwQApbwwrof862rrH8YU0QP3gVENMU4TRpZx
9jdnJk+OZJpFo74XitnrWDsprY1r/lJdGaLnebfg9DztbjHVgCWvkRNXI7qIbRpf
QfSeMusrhVwDNITBhJ/0j+A1phWUQG6CU0dez+iKvCJUcohgDlFmlIsw8tCkgDYG
On7b7ZKlHd8=
=kLcU
-----END PGP SIGNATURE-----

From martin at v.loewis.de  Tue Aug 12 06:43:23 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 12 Aug 2008 06:43:23 +0200
Subject: [python-committers] [Python-Dev] next beta
In-Reply-To: <6D041763-67AC-4213-AF2B-4AFBB991C699@python.org>
References: <4838EA2D.7060402@jcea.es>	<319e029f0806020752necf5acer9866c158ce9ac286@mail.gmail.com>	<488150A5.8050804@jcea.es>	<B98D6CBA-6D19-482F-B11D-1FF60B77F17A@barrys-emacs.org>	<488451AB.50406@jcea.es>
	<g61jt8$hag$2@ger.gmane.org>	<4884581F.8010201@jcea.es>	<bbaeab100807211116g4df70dc1o81b1075a88282c93@mail.gmail.com>	<1BDCADF2-F6EE-4824-80BF-68CB1760CA7B@python.org>	<loom.20080811T095014-204@post.gmane.org>	<2F883F29-DAD8-4D4D-948D-DDAD872EB2A4@python.org>
	<6D041763-67AC-4213-AF2B-4AFBB991C699@python.org>
Message-ID: <48A114EB.3090801@v.loewis.de>

> It sounds like Wednesday August 13th will not be feasible, so we'll do
> beta 3 on Wednesday August 20th.  I've updated both the PEP and the
> Google Calendar.

I'll be on vacation then, and not be able to produce Windows binaries
(until September 8)

Regards,
Martin

From martin at v.loewis.de  Tue Aug 12 08:28:17 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 12 Aug 2008 08:28:17 +0200
Subject: [python-committers] [Python-Dev] next beta
In-Reply-To: <e69d3ed20808112308n2ed1739fv3ecb79e2fa1de279@mail.gmail.com>
References: <4838EA2D.7060402@jcea.es> <488451AB.50406@jcea.es>	
	<g61jt8$hag$2@ger.gmane.org> <4884581F.8010201@jcea.es>	
	<bbaeab100807211116g4df70dc1o81b1075a88282c93@mail.gmail.com>	
	<1BDCADF2-F6EE-4824-80BF-68CB1760CA7B@python.org>	
	<loom.20080811T095014-204@post.gmane.org>	
	<2F883F29-DAD8-4D4D-948D-DDAD872EB2A4@python.org>	
	<6D041763-67AC-4213-AF2B-4AFBB991C699@python.org>	
	<48A114EB.3090801@v.loewis.de>
	<e69d3ed20808112308n2ed1739fv3ecb79e2fa1de279@mail.gmail.com>
Message-ID: <48A12D81.1040309@v.loewis.de>

Anthony Baxter wrote:
> darn. I was hoping to get a 2.5.3 rc and final out soon. Can anyone
> else build the binaries?

For the 2.5, the challenge is to produce AMD64 and Itanium binaries,
using vsextcomp (plus the usual problems of collecting all the
necessary packages and build them first).

Are you also planning to produce a 2.4 security (source only) release?
Will the 2.5 release be the final bug fix release?

Regards,
Martin

From tnelson at onresolve.com  Tue Aug 12 09:02:18 2008
From: tnelson at onresolve.com (Trent Nelson)
Date: Tue, 12 Aug 2008 08:02:18 +0100
Subject: [python-committers] Nominate Hirokazu Yamamoto (oceancity) for
 commit privs.
In-Reply-To: <6167796BFEB5D0438720AC212E89A6B0078F4D64@exchange.onresolve.com>
References: <6167796BFEB5D0438720AC212E89A6B0078F4D64@exchange.onresolve.com>
Message-ID: <6167796BFEB5D0438720AC212E89A6B0078F4D67@exchange.onresolve.com>

Hi there Hirokazu Yamamoto,

Some of the other Python developers and myself are interested in knowing whether or not you'd like to become a Python committer.  We've noticed you're very active in the issue tracker and you always seem to be able to provide patches when the VC6/VC8 Python builds break (Christian Heimes would like to nominate you as the maintainer for the VC6/VC8 builds).

If you're interested all we need from you is a login name (i.e. hirokazu.yamamoto or yamamoto.hirokazu if you prefer), an e-mail address so you can be subscribed to python-committers, and an ssh public key.  Instructions for generating a key can be found in the Python Developer FAQ:

http://www.python.org/dev/faq/#how-do-i-generate-an-ssh-2-public-key

(You can send your public key to Martin: martin at v.loewis.de.)

Look forward to hearing from you.  Thanks for your work with Python so far!

Regards,

        Trent.

> -----Original Message-----
> From: python-committers-bounces at python.org [mailto:python-
> committers-bounces at python.org] On Behalf Of Trent Nelson
> Sent: 11 August 2008 20:28
> To: python-committers at python.org
> Subject: [python-committers] Nominate Hirokazu Yamamoto (oceancity)
> for commit privs.
>
>
> What do people think about making Hirokazu Yamamoto a committer?  I
> rarely see any mailing list posts from him, but he sure makes up
> for it in terms of patches submitted to the issue tracker.  As far
> as I can tell (I've noticed his regular involvement via patches and
> whatnot for well over a year), he's a pretty switched on guy with a
> lot of Windows experience -- every time trunk fails to build with
> vc6/7/8, for example, he's got patches lined up.
>
>
>         Trent.
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> http://mail.python.org/mailman/listinfo/python-committers

From anthonybaxter at gmail.com  Tue Aug 12 08:08:54 2008
From: anthonybaxter at gmail.com (Anthony Baxter)
Date: Tue, 12 Aug 2008 16:08:54 +1000
Subject: [python-committers] [Python-Dev] next beta
In-Reply-To: <48A114EB.3090801@v.loewis.de>
References: <4838EA2D.7060402@jcea.es> <488451AB.50406@jcea.es>
	<g61jt8$hag$2@ger.gmane.org> <4884581F.8010201@jcea.es>
	<bbaeab100807211116g4df70dc1o81b1075a88282c93@mail.gmail.com>
	<1BDCADF2-F6EE-4824-80BF-68CB1760CA7B@python.org>
	<loom.20080811T095014-204@post.gmane.org>
	<2F883F29-DAD8-4D4D-948D-DDAD872EB2A4@python.org>
	<6D041763-67AC-4213-AF2B-4AFBB991C699@python.org>
	<48A114EB.3090801@v.loewis.de>
Message-ID: <e69d3ed20808112308n2ed1739fv3ecb79e2fa1de279@mail.gmail.com>

darn. I was hoping to get a 2.5.3 rc and final out soon. Can anyone
else build the binaries?




On Tue, Aug 12, 2008 at 2:43 PM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
>> It sounds like Wednesday August 13th will not be feasible, so we'll do
>> beta 3 on Wednesday August 20th.  I've updated both the PEP and the
>> Google Calendar.
>
> I'll be on vacation then, and not be able to produce Windows binaries
> (until September 8)
>
> Regards,
> Martin
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> http://mail.python.org/mailman/listinfo/python-committers
>
>

From anthonybaxter at gmail.com  Tue Aug 12 08:54:04 2008
From: anthonybaxter at gmail.com (Anthony Baxter)
Date: Tue, 12 Aug 2008 16:54:04 +1000
Subject: [python-committers] [Python-Dev] next beta
In-Reply-To: <48A12D81.1040309@v.loewis.de>
References: <4838EA2D.7060402@jcea.es> <4884581F.8010201@jcea.es>
	<bbaeab100807211116g4df70dc1o81b1075a88282c93@mail.gmail.com>
	<1BDCADF2-F6EE-4824-80BF-68CB1760CA7B@python.org>
	<loom.20080811T095014-204@post.gmane.org>
	<2F883F29-DAD8-4D4D-948D-DDAD872EB2A4@python.org>
	<6D041763-67AC-4213-AF2B-4AFBB991C699@python.org>
	<48A114EB.3090801@v.loewis.de>
	<e69d3ed20808112308n2ed1739fv3ecb79e2fa1de279@mail.gmail.com>
	<48A12D81.1040309@v.loewis.de>
Message-ID: <e69d3ed20808112354t6cb1a55esbc90126b573fb18b@mail.gmail.com>

I am planning to offer a single file patch for 2.3 and 2.4. As far as
one more 2.5 release, I don't think there's going to be many changes
to the 2.5 branch between now and 2.6/3.0 final - although if there
is, we'll obviously have to do another release.

I wouldn't be horribly surprised if more nasty lurking bugs remain in
the C code. The google security review found a bunch, apple found
some, but there's really quite a lot of code there...



On Tue, Aug 12, 2008 at 4:28 PM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> Anthony Baxter wrote:
>> darn. I was hoping to get a 2.5.3 rc and final out soon. Can anyone
>> else build the binaries?
>
> For the 2.5, the challenge is to produce AMD64 and Itanium binaries,
> using vsextcomp (plus the usual problems of collecting all the
> necessary packages and build them first).
>
> Are you also planning to produce a 2.4 security (source only) release?
> Will the 2.5 release be the final bug fix release?
>
> Regards,
> Martin
>

From asmodai at in-nomine.org  Tue Aug 12 09:23:28 2008
From: asmodai at in-nomine.org (Jeroen Ruigrok van der Werven)
Date: Tue, 12 Aug 2008 09:23:28 +0200
Subject: [python-committers] [Python-Dev] next beta
In-Reply-To: <48A12D81.1040309@v.loewis.de>
References: <g61jt8$hag$2@ger.gmane.org> <4884581F.8010201@jcea.es>
	<bbaeab100807211116g4df70dc1o81b1075a88282c93@mail.gmail.com>
	<1BDCADF2-F6EE-4824-80BF-68CB1760CA7B@python.org>
	<loom.20080811T095014-204@post.gmane.org>
	<2F883F29-DAD8-4D4D-948D-DDAD872EB2A4@python.org>
	<6D041763-67AC-4213-AF2B-4AFBB991C699@python.org>
	<48A114EB.3090801@v.loewis.de>
	<e69d3ed20808112308n2ed1739fv3ecb79e2fa1de279@mail.gmail.com>
	<48A12D81.1040309@v.loewis.de>
Message-ID: <20080812072328.GP57679@nexus.in-nomine.org>

-On [20080812 08:28], "Martin v. L?wis" (martin at v.loewis.de) wrote:
>For the 2.5, the challenge is to produce AMD64 and Itanium binaries,
>using vsextcomp (plus the usual problems of collecting all the
>necessary packages and build them first).

I have a Windows x64 box at home. Which Visual Studio was now needed, 2008?

If you want Martin, we can go over making sure I got a build environment set
up as well?

-- 
Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai
????? ?????? ??? ?? ??????
http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B
Sorrow paid for valour is too much to recall...

From martin at v.loewis.de  Tue Aug 12 09:38:34 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 12 Aug 2008 09:38:34 +0200
Subject: [python-committers] [Python-Dev] next beta
In-Reply-To: <e69d3ed20808112354t6cb1a55esbc90126b573fb18b@mail.gmail.com>
References: <4838EA2D.7060402@jcea.es> <4884581F.8010201@jcea.es>	
	<bbaeab100807211116g4df70dc1o81b1075a88282c93@mail.gmail.com>	
	<1BDCADF2-F6EE-4824-80BF-68CB1760CA7B@python.org>	
	<loom.20080811T095014-204@post.gmane.org>	
	<2F883F29-DAD8-4D4D-948D-DDAD872EB2A4@python.org>	
	<6D041763-67AC-4213-AF2B-4AFBB991C699@python.org>	
	<48A114EB.3090801@v.loewis.de>	
	<e69d3ed20808112308n2ed1739fv3ecb79e2fa1de279@mail.gmail.com>	
	<48A12D81.1040309@v.loewis.de>
	<e69d3ed20808112354t6cb1a55esbc90126b573fb18b@mail.gmail.com>
Message-ID: <48A13DFA.3080504@v.loewis.de>

Anthony Baxter wrote:
> I am planning to offer a single file patch for 2.3 and 2.4. As far as
> one more 2.5 release, I don't think there's going to be many changes
> to the 2.5 branch between now and 2.6/3.0 final - although if there
> is, we'll obviously have to do another release.

I would like to establish a tradition where, after some final bug fix
release (e.g. for 2.5), further "mere" bug fixes are banned from the
maintenance branch (and I did revert several bug fixes from the 2.4
branch). Only security-relevant patches would be allowed to the branch.
>From such a branch, only source releases will be created, for a period
of five years.

So I would rather
- declare that the next 2.5 release will be the final one, and that
  any bug fixes that are not security fixes must be committed now.
  I know some Linux distributors have patches that they still want to
  see integrated.
- after some announcement of such an upcoming 2.5 release, create
  release candidate, release, documentation, and windows binaries.
- also create a 2.4 release, as a source-only release (i.e. no
  documentation update or windows binaries)
- leave 2.3 alone (it's more than 5 years since the initial 2.3
  release)

Realistically, I would schedule such a 2.5 release after 2.6 and 3.0
have been released (and indeed was planning to do so myself).

If you feel the urgency of doing something now, how about *only*
providing patches for 2.5 at the moment? ActiveState might integrate
them into ActivePython; system vendors can also pick them up
(if they haven't already).

Regards,
Martin

From martin at v.loewis.de  Tue Aug 12 09:43:22 2008
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Tue, 12 Aug 2008 09:43:22 +0200
Subject: [python-committers] [Python-Dev] next beta
In-Reply-To: <20080812072328.GP57679@nexus.in-nomine.org>
References: <g61jt8$hag$2@ger.gmane.org> <4884581F.8010201@jcea.es>
	<bbaeab100807211116g4df70dc1o81b1075a88282c93@mail.gmail.com>
	<1BDCADF2-F6EE-4824-80BF-68CB1760CA7B@python.org>
	<loom.20080811T095014-204@post.gmane.org>
	<2F883F29-DAD8-4D4D-948D-DDAD872EB2A4@python.org>
	<6D041763-67AC-4213-AF2B-4AFBB991C699@python.org>
	<48A114EB.3090801@v.loewis.de>
	<e69d3ed20808112308n2ed1739fv3ecb79e2fa1de279@mail.gmail.com>
	<48A12D81.1040309@v.loewis.de>
	<20080812072328.GP57679@nexus.in-nomine.org>
Message-ID: <48A13F1A.7050200@v.loewis.de>

Jeroen Ruigrok van der Werven wrote:
> -On [20080812 08:28], "Martin v. L?wis" (martin at v.loewis.de) wrote:
>> For the 2.5, the challenge is to produce AMD64 and Itanium binaries,
>> using vsextcomp (plus the usual problems of collecting all the
>> necessary packages and build them first).
> 
> I have a Windows x64 box at home. Which Visual Studio was now needed, 2008?

2003, along with a platform SDK, and vsextcomp, and we would need both
AMD64 and IA64 binaries (although it's probably ok if the Itanium
binaries aren't tested as long as you can verify that they are IA64
binaries).

> If you want Martin, we can go over making sure I got a build environment set
> up as well?

I'm leaving Sunday - not sure whether that's enough time to set things up.

Regards,
Martin

From barry at python.org  Tue Aug 12 13:40:14 2008
From: barry at python.org (Barry Warsaw)
Date: Tue, 12 Aug 2008 07:40:14 -0400
Subject: [python-committers] [Python-Dev] next beta
In-Reply-To: <e69d3ed20808112354t6cb1a55esbc90126b573fb18b@mail.gmail.com>
References: <4838EA2D.7060402@jcea.es> <4884581F.8010201@jcea.es>
	<bbaeab100807211116g4df70dc1o81b1075a88282c93@mail.gmail.com>
	<1BDCADF2-F6EE-4824-80BF-68CB1760CA7B@python.org>
	<loom.20080811T095014-204@post.gmane.org>
	<2F883F29-DAD8-4D4D-948D-DDAD872EB2A4@python.org>
	<6D041763-67AC-4213-AF2B-4AFBB991C699@python.org>
	<48A114EB.3090801@v.loewis.de>
	<e69d3ed20808112308n2ed1739fv3ecb79e2fa1de279@mail.gmail.com>
	<48A12D81.1040309@v.loewis.de>
	<e69d3ed20808112354t6cb1a55esbc90126b573fb18b@mail.gmail.com>
Message-ID: <161D5566-E2C4-4E37-8090-5BFC1DAB5EF4@python.org>

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

On Aug 12, 2008, at 2:54 AM, Anthony Baxter wrote:

> I am planning to offer a single file patch for 2.3 and 2.4.

It shouldn't be hard to build source tarballs, though I also don't  
know if it's worth it.  We should leave the option open if there's  
demand.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSKF2nnEjvBPtnXfVAQL2CAP+NKyc63DyNwCE3iopBJU/u1LjpZ/TT1H+
ujzPVB/f/QtoXiFp+fRbWK0HTn9u1t7ts0R/FMgxop66BQB8lAqWVDY+D8WBM3It
DcO10GWWd4oLezfi346tqru7DqwoPOlXzy3e6esliEBg/1SCiZMB8BPVZinJFSvk
njPAK5VkWeo=
=1cm8
-----END PGP SIGNATURE-----

From barry at python.org  Tue Aug 12 14:18:21 2008
From: barry at python.org (Barry Warsaw)
Date: Tue, 12 Aug 2008 08:18:21 -0400
Subject: [python-committers] [Python-Dev] next beta
In-Reply-To: <48A13DFA.3080504@v.loewis.de>
References: <4838EA2D.7060402@jcea.es> <4884581F.8010201@jcea.es>	
	<bbaeab100807211116g4df70dc1o81b1075a88282c93@mail.gmail.com>	
	<1BDCADF2-F6EE-4824-80BF-68CB1760CA7B@python.org>	
	<loom.20080811T095014-204@post.gmane.org>	
	<2F883F29-DAD8-4D4D-948D-DDAD872EB2A4@python.org>	
	<6D041763-67AC-4213-AF2B-4AFBB991C699@python.org>	
	<48A114EB.3090801@v.loewis.de>	
	<e69d3ed20808112308n2ed1739fv3ecb79e2fa1de279@mail.gmail.com>	
	<48A12D81.1040309@v.loewis.de>
	<e69d3ed20808112354t6cb1a55esbc90126b573fb18b@mail.gmail.com>
	<48A13DFA.3080504@v.loewis.de>
Message-ID: <557787AE-51CD-49EB-B16F-C22F45B9F51E@python.org>

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

On Aug 12, 2008, at 3:38 AM, Martin v. L?wis wrote:

> Anthony Baxter wrote:
>> I am planning to offer a single file patch for 2.3 and 2.4. As far as
>> one more 2.5 release, I don't think there's going to be many changes
>> to the 2.5 branch between now and 2.6/3.0 final - although if there
>> is, we'll obviously have to do another release.
>
> I would like to establish a tradition where, after some final bug fix
> release (e.g. for 2.5), further "mere" bug fixes are banned from the
> maintenance branch (and I did revert several bug fixes from the 2.4
> branch).

I'm not sure I agree with this policy.  Can you elaborate on /why/ you  
want this?

I understand that we're a volunteer organization, and that our  
resources are limited.  I'm also wary about siphoning off those limit  
resources right now for working on other than 2.6 and 3.0, but I'm not  
sure that this policy really buys us much there. E.g. with this policy  
you'll need a release cop to patrol commits and back out non-security  
fixes right away.  It's much more work to revert such changes whenever  
we get around to doing the release.  Seems like it could be /more/  
work with this policy.

I do agree that we need to be very careful about introducing new  
features, but I think non-security patches can be okay.

I had some 2.4 patches backed out because they weren't security  
releases.  I was okay with it at the time, but I'm uncomfortable about  
imposing this as a general rule.  If we have bugs, and we have someone  
motivated to fix them, we should opt toward fixing them.  It's  
demoralizing to have one's patches backed out.  Besides, we still have  
downstream vendors that are maintaining and releasing Python 2.4; does  
this mean they're out of luck for bug fixes or they have to roll their  
own?

We're on an 18 month release schedule, which is a long time to wait,  
so I'm not in favor of an arbitrary date for cutting off "mere" bug  
fixes.  Rather, I'd like to see a policy (but not a promise) of  
supporting two releases at a time.  Thus, when 2.6 is released, we  
would stop support for all but critical security fixes for 2.4, but we  
could (not will) still release bug fixes for 2.5.  And of course,  
we'll support 2.6/3.0 while 2.7/3.1 is being developed.

Having lockstep 2.x and 3.x release complicates things a bit, but  
because they are lockstep, I'm thinking of them more as the same  
release rather than separate ones.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSKF/jnEjvBPtnXfVAQIQdAQArojNCP9pEwrNxxYQgky5j36nO9buQlP2
c43AmS0xCa+OKK/fL1QEcza1n6B7j1fT/w6Cf429Rtdsh9tNwig5NVJDTuD/5rRg
RXNJiBKsr69uba8ITV/qO8J1hEuew15w6exBXOMnAUpdoXpxafqg2ycoFmK3/C6E
ZAXnDYAgFoc=
=pkeW
-----END PGP SIGNATURE-----

From tnelson at onresolve.com  Tue Aug 12 14:33:57 2008
From: tnelson at onresolve.com (Trent Nelson)
Date: Tue, 12 Aug 2008 13:33:57 +0100
Subject: [python-committers] [Python-Dev] next beta
In-Reply-To: <48A13F1A.7050200@v.loewis.de>
References: <g61jt8$hag$2@ger.gmane.org> <4884581F.8010201@jcea.es>
	<bbaeab100807211116g4df70dc1o81b1075a88282c93@mail.gmail.com>
	<1BDCADF2-F6EE-4824-80BF-68CB1760CA7B@python.org>
	<loom.20080811T095014-204@post.gmane.org>
	<2F883F29-DAD8-4D4D-948D-DDAD872EB2A4@python.org>
	<6D041763-67AC-4213-AF2B-4AFBB991C699@python.org>
	<48A114EB.3090801@v.loewis.de>
	<e69d3ed20808112308n2ed1739fv3ecb79e2fa1de279@mail.gmail.com>
	<48A12D81.1040309@v.loewis.de>	<20080812072328.GP57679@nexus.in-nomine.org>
	<48A13F1A.7050200@v.loewis.de>
Message-ID: <6167796BFEB5D0438720AC212E89A6B0078F4D6D@exchange.onresolve.com>

I'll put my hand up for doing the Windows build as well (the x64 buildbot has all the necessary bits and pieces installed).  I know some HP people that I could rope in to install the resulting IA64 build and run rt.bat.

We're not shipping PGO builds for 2.5.x are we?

Martin, not sure if you've had a chance to do anything with the VeriSign certificates?  (Ambiguous question mark intended ;-)

        Trent.

> -----Original Message-----
> From: python-committers-bounces at python.org [mailto:python-
> committers-bounces at python.org] On Behalf Of "Martin v. L?wis"
> Sent: 12 August 2008 08:43
> To: Jeroen Ruigrok van der Werven
> Cc: python-committers at python.org
> Subject: Re: [python-committers] [Python-Dev] next beta
>
> Jeroen Ruigrok van der Werven wrote:
> > -On [20080812 08:28], "Martin v. L?wis" (martin at v.loewis.de)
> wrote:
> >> For the 2.5, the challenge is to produce AMD64 and Itanium
> binaries,
> >> using vsextcomp (plus the usual problems of collecting all the
> >> necessary packages and build them first).
> >
> > I have a Windows x64 box at home. Which Visual Studio was now
> needed, 2008?
>
> 2003, along with a platform SDK, and vsextcomp, and we would need
> both
> AMD64 and IA64 binaries (although it's probably ok if the Itanium
> binaries aren't tested as long as you can verify that they are IA64
> binaries).
>
> > If you want Martin, we can go over making sure I got a build
> environment set
> > up as well?
>
> I'm leaving Sunday - not sure whether that's enough time to set
> things up.
>
> Regards,
> Martin
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> http://mail.python.org/mailman/listinfo/python-committers

From trentm at activestate.com  Tue Aug 12 18:49:05 2008
From: trentm at activestate.com (Trent Mick)
Date: Tue, 12 Aug 2008 09:49:05 -0700
Subject: [python-committers] [Python-Dev] next beta
In-Reply-To: <48A13DFA.3080504@v.loewis.de>
References: <4838EA2D.7060402@jcea.es>
	<4884581F.8010201@jcea.es>		<bbaeab100807211116g4df70dc1o81b1075a88282c93@mail.gmail.com>		<1BDCADF2-F6EE-4824-80BF-68CB1760CA7B@python.org>		<loom.20080811T095014-204@post.gmane.org>		<2F883F29-DAD8-4D4D-948D-DDAD872EB2A4@python.org>		<6D041763-67AC-4213-AF2B-4AFBB991C699@python.org>		<48A114EB.3090801@v.loewis.de>		<e69d3ed20808112308n2ed1739fv3ecb79e2fa1de279@mail.gmail.com>		<48A12D81.1040309@v.loewis.de>	<e69d3ed20808112354t6cb1a55esbc90126b573fb18b@mail.gmail.com>
	<48A13DFA.3080504@v.loewis.de>
Message-ID: <48A1BF01.7010809@activestate.com>

Martin v. L?wis wrote:
> If you feel the urgency of doing something now, how about *only*
> providing patches for 2.5 at the moment? ActiveState might integrate
> them into ActivePython; system vendors can also pick them up
> (if they haven't already).

I *could* integrate patches into an ActivePython release. But I've found 
that there is value in having ActivePython using (mostly) the exact same 
sources as a python.org release. Depends on the patches, I guess.

Trent

-- 
Trent Mick
trentm at activestate.com

From martin at v.loewis.de  Tue Aug 12 20:44:42 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 12 Aug 2008 20:44:42 +0200
Subject: [python-committers] [Python-Dev] next beta
In-Reply-To: <557787AE-51CD-49EB-B16F-C22F45B9F51E@python.org>
References: <4838EA2D.7060402@jcea.es> <4884581F.8010201@jcea.es>	
	<bbaeab100807211116g4df70dc1o81b1075a88282c93@mail.gmail.com>	
	<1BDCADF2-F6EE-4824-80BF-68CB1760CA7B@python.org>	
	<loom.20080811T095014-204@post.gmane.org>	
	<2F883F29-DAD8-4D4D-948D-DDAD872EB2A4@python.org>	
	<6D041763-67AC-4213-AF2B-4AFBB991C699@python.org>	
	<48A114EB.3090801@v.loewis.de>	
	<e69d3ed20808112308n2ed1739fv3ecb79e2fa1de279@mail.gmail.com>	
	<48A12D81.1040309@v.loewis.de>
	<e69d3ed20808112354t6cb1a55esbc90126b573fb18b@mail.gmail.com>
	<48A13DFA.3080504@v.loewis.de>
	<557787AE-51CD-49EB-B16F-C22F45B9F51E@python.org>
Message-ID: <48A1DA1A.7090103@v.loewis.de>

>>> I am planning to offer a single file patch for 2.3 and 2.4. As far as
>>> one more 2.5 release, I don't think there's going to be many changes
>>> to the 2.5 branch between now and 2.6/3.0 final - although if there
>>> is, we'll obviously have to do another release.
> 
>> I would like to establish a tradition where, after some final bug fix
>> release (e.g. for 2.5), further "mere" bug fixes are banned from the
>> maintenance branch (and I did revert several bug fixes from the 2.4
>> branch).
> 
> I'm not sure I agree with this policy.  Can you elaborate on /why/ you
> want this?

Because there won't typically be sufficient testing and release
infrastructure to allow arbitrary bug fixes to be committed on the
branch. The buildbots are turned off, and nobody tests the release
candidate, no Windows binaries are provided - thus, chances are very
high that a bug fix release for some very old branch will be *worse*
than the previous release, rather than better.

An alternative would be to keep all infrastructure up and running,
but that is infeasible.

> I understand that we're a volunteer organization, and that our resources
> are limited.  I'm also wary about siphoning off those limit resources
> right now for working on other than 2.6 and 3.0, but I'm not sure that
> this policy really buys us much there. E.g. with this policy you'll need
> a release cop to patrol commits and back out non-security fixes right
> away.

That's not necessary. When I made 2.3.7 and 2.4.5, I went through the
complete log, and posted a list of patches that I wanted to revert.
This was little effort, and I'm sure it would have been even less effort
if people had known that 2.4.x is a closed branch.

> It's much more work to revert such changes whenever we get around
> to doing the release.  Seems like it could be /more/ work with this policy.

It wasn't really that much work - there were little non-security
patches, and they were easily identifiable from the commit message.

> I do agree that we need to be very careful about introducing new
> features, but I think non-security patches can be okay.

They aren't, as they don't get sufficient testing.

> It's
> demoralizing to have one's patches backed out.  Besides, we still have
> downstream vendors that are maintaining and releasing Python 2.4; does
> this mean they're out of luck for bug fixes or they have to roll their own?

I've talked to the downstream vendors, and they really want security
patches for a long time, above all. They are fine with maintaining their
own patches (which they do, anyway).

> We're on an 18 month release schedule, which is a long time to wait, so
> I'm not in favor of an arbitrary date for cutting off "mere" bug fixes. 
> Rather, I'd like to see a policy (but not a promise) of supporting two
> releases at a time.

I think this requires more resources than we have - especially with
your way of counting:

> Thus, when 2.6 is released, we would stop support
> for all but critical security fixes for 2.4, but we could (not will)
> still release bug fixes for 2.5.  And of course, we'll support 2.6/3.0
> while 2.7/3.1 is being developed.

So that's *three* branches that we need to maintain, right: 2.5, 2.6,
and 3.0. Once 3.1 is released, I supposed it's even *four* branches:
2.6, 2.7, 3.0, and 3.1. That means that every change must be
committed/merged four times, you need to run the test suite four times,
and so on. Depending on the nature of the bug fix, you also need to
keep the specifics of the four branches in mind.

I don't think our committers will accept such a work load - which means
that some patches don't get backported (arbitrarily, depending on how
relevant the committer views that policy).

> Having lockstep 2.x and 3.x release complicates things a bit, but
> because they are lockstep, I'm thinking of them more as the same release
> rather than separate ones.

I think this is an illusion. When did you last commit something to the
trunk, and forward-ported it to the 3.0 branch? When did you last run
"svnmerge avail"? Porting patches between 2.6 and 3.0 is anything but
trivial.

Regards,
Martin

From martin at v.loewis.de  Tue Aug 12 20:49:46 2008
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Tue, 12 Aug 2008 20:49:46 +0200
Subject: [python-committers] [Python-Dev] next beta
In-Reply-To: <6167796BFEB5D0438720AC212E89A6B0078F4D6D@exchange.onresolve.com>
References: <g61jt8$hag$2@ger.gmane.org>
	<4884581F.8010201@jcea.es>	<bbaeab100807211116g4df70dc1o81b1075a88282c93@mail.gmail.com>	<1BDCADF2-F6EE-4824-80BF-68CB1760CA7B@python.org>	<loom.20080811T095014-204@post.gmane.org>	<2F883F29-DAD8-4D4D-948D-DDAD872EB2A4@python.org>	<6D041763-67AC-4213-AF2B-4AFBB991C699@python.org>	<48A114EB.3090801@v.loewis.de>	<e69d3ed20808112308n2ed1739fv3ecb79e2fa1de279@mail.gmail.com>	<48A12D81.1040309@v.loewis.de>	<20080812072328.GP57679@nexus.in-nomine.org>
	<48A13F1A.7050200@v.loewis.de>
	<6167796BFEB5D0438720AC212E89A6B0078F4D6D@exchange.onresolve.com>
Message-ID: <48A1DB4A.9070301@v.loewis.de>

> I'll put my hand up for doing the Windows build as well (the x64
> buildbot has all the necessary bits and pieces installed).  I know
> some HP people that I could rope in to install the resulting IA64
> build and run rt.bat.


Notice that we both look for somebody to build the next 2.6/3.0 betas
(see the subject), and the 2.5.3 rc and final release (assuming Anthony
still has that plan).

My testing on Itanium is the mere "does it install?", "can I start both
cmdline and IDLE?", "is the help file the right one?". The test suite
itself will fail/hang - it always did in 2.5.x.

> We're not shipping PGO builds for 2.5.x are we?

No. I don't think VS 2003 supported that. I don't do PGO for the AMD64
build of 2.6/3.0, either, because I also have a cross-compilation
environment which prevents that.

> Martin, not sure if you've had a chance to do anything with the
> VeriSign certificates?  (Ambiguous question mark intended ;-)

Please see the most recent MSI files - they are all signed.

Regards,
Martin

From ocean-city at m2.ccsnet.ne.jp  Tue Aug 12 20:01:20 2008
From: ocean-city at m2.ccsnet.ne.jp (Hirokazu Yamamoto)
Date: Wed, 13 Aug 2008 03:01:20 +0900
Subject: [python-committers] Nominate Hirokazu Yamamoto (oceancity) for
	commit privs.
References: <6167796BFEB5D0438720AC212E89A6B0078F4D64@exchange.onresolve.com>
	<6167796BFEB5D0438720AC212E89A6B0078F4D67@exchange.onresolve.com>
Message-ID: <006b01c8fca5$6d11b6e0$0200a8c0@whiterabc2znlh>

Thank you for sweet invitation, python committers!

>We've noticed you're very active in the issue tracker and you always seem
>to be able to provide patches when the VC6/VC8 Python builds break
>(Christian Heimes would like to nominate you as the maintainer for the
>VC6/VC8 builds).

Yes, I have VC6, but I don't  have VC8.  It is true that the change required
for VC6 is often required for VC8 too, but I cannot test VC8 directly.
Are you OK about it?

>If you're interested all we need from you is a login name (i.e.
>hirokazu.yamamoto or yamamoto.hirokazu if you prefer), an e-mail
>address so you can be subscribed to python-committers, and an ssh
>public key.  Instructions for generating a key can be found in the
>Python Developer FAQ:

I prefer hirokazu.yamamoto (hirokazu is given name, yamamoto is family name)
Please use ocean-city at m2.ccsnet.ne.jp as email address.
I'll send SSH public key to MvL. Thank you.


From brett at python.org  Tue Aug 12 21:34:59 2008
From: brett at python.org (Brett Cannon)
Date: Tue, 12 Aug 2008 12:34:59 -0700
Subject: [python-committers] Nominate Hirokazu Yamamoto (oceancity) for
	commit privs.
In-Reply-To: <006b01c8fca5$6d11b6e0$0200a8c0@whiterabc2znlh>
References: <6167796BFEB5D0438720AC212E89A6B0078F4D64@exchange.onresolve.com>
	<6167796BFEB5D0438720AC212E89A6B0078F4D67@exchange.onresolve.com>
	<006b01c8fca5$6d11b6e0$0200a8c0@whiterabc2znlh>
Message-ID: <bbaeab100808121234h5312a150g8499884a1bbef2b1@mail.gmail.com>

On Tue, Aug 12, 2008 at 11:01 AM, Hirokazu Yamamoto
<ocean-city at m2.ccsnet.ne.jp> wrote:
> Thank you for sweet invitation, python committers!
>
[SNIP]
> Please use ocean-city at m2.ccsnet.ne.jp as email address.

You have now been subscribed, Hirokazu.

-Brett

From tnelson at onresolve.com  Wed Aug 13 17:32:01 2008
From: tnelson at onresolve.com (Trent Nelson)
Date: Wed, 13 Aug 2008 16:32:01 +0100
Subject: [python-committers] [Python-Dev] next beta
In-Reply-To: <48A1DB4A.9070301@v.loewis.de>
References: <g61jt8$hag$2@ger.gmane.org> <4884581F.8010201@jcea.es>
	<bbaeab100807211116g4df70dc1o81b1075a88282c93@mail.gmail.com>
	<1BDCADF2-F6EE-4824-80BF-68CB1760CA7B@python.org>
	<loom.20080811T095014-204@post.gmane.org>
	<2F883F29-DAD8-4D4D-948D-DDAD872EB2A4@python.org>
	<6D041763-67AC-4213-AF2B-4AFBB991C699@python.org>
	<48A114EB.3090801@v.loewis.de>
	<e69d3ed20808112308n2ed1739fv3ecb79e2fa1de279@mail.gmail.com>
	<48A12D81.1040309@v.loewis.de>	<20080812072328.GP57679@nexus.in-nomine.org>
	<48A13F1A.7050200@v.loewis.de>
	<6167796BFEB5D0438720AC212E89A6B0078F4D6D@exchange.onresolve.com>
	<48A1DB4A.9070301@v.loewis.de>
Message-ID: <6167796BFEB5D0438720AC212E89A6B0078F4D8B@exchange.onresolve.com>

> > I'll put my hand up for doing the Windows build as well (the x64
> > buildbot has all the necessary bits and pieces installed).  I
> > know some HP people that I could rope in to install the resulting
> > IA64 build and run rt.bat.

> Notice that we both look for somebody to build the next 2.6/3.0
> betas (see the subject), and the 2.5.3 rc and final release
> (assuming Anthony still has that plan).

I'd like to offer my Win2k8 x64 colo box for building Python installers.  It's a Hyper-V instance with four cores, 4GB of RAM and plenty of disk space, and has just about every Microsoft-oriented development tool installed produced this decade (inc. Itanium compilers).

So, ideally, any committer that's interested in being able to produce the official Python binaries can drop me a note and I'll give them remote access.  That way we've got a single 'build server' for producing releases, as well as multiple people with the capacity to perform such builds.

I'm probably biased because it's a freakin' expensive colo and I'm severely under-utilising the box (host is an 8-core 8GB monster), but I'd argue that a nominated build server is more desirable for official releases than someone's laptop.

Thoughts?

(Even if we don't go down this path, if other developers would like remote access to the box just drop me an e-mail.  I specifically acquired it to 'donate' to Python-oriented activities; no-one else has access to it.)

        Trent.

From barry at python.org  Thu Aug 14 00:33:13 2008
From: barry at python.org (Barry Warsaw)
Date: Wed, 13 Aug 2008 18:33:13 -0400
Subject: [python-committers] [Python-Dev] next beta
In-Reply-To: <48A1DA1A.7090103@v.loewis.de>
References: <4838EA2D.7060402@jcea.es> <4884581F.8010201@jcea.es>	
	<bbaeab100807211116g4df70dc1o81b1075a88282c93@mail.gmail.com>	
	<1BDCADF2-F6EE-4824-80BF-68CB1760CA7B@python.org>	
	<loom.20080811T095014-204@post.gmane.org>	
	<2F883F29-DAD8-4D4D-948D-DDAD872EB2A4@python.org>	
	<6D041763-67AC-4213-AF2B-4AFBB991C699@python.org>	
	<48A114EB.3090801@v.loewis.de>	
	<e69d3ed20808112308n2ed1739fv3ecb79e2fa1de279@mail.gmail.com>	
	<48A12D81.1040309@v.loewis.de>
	<e69d3ed20808112354t6cb1a55esbc90126b573fb18b@mail.gmail.com>
	<48A13DFA.3080504@v.loewis.de>
	<557787AE-51CD-49EB-B16F-C22F45B9F51E@python.org>
	<48A1DA1A.7090103@v.loewis.de>
Message-ID: <4F0CDE78-146A-493B-BD7D-7D67291E2799@python.org>

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

On Aug 12, 2008, at 2:44 PM, Martin v. L?wis wrote:

>>>> I am planning to offer a single file patch for 2.3 and 2.4. As  
>>>> far as
>>>> one more 2.5 release, I don't think there's going to be many  
>>>> changes
>>>> to the 2.5 branch between now and 2.6/3.0 final - although if there
>>>> is, we'll obviously have to do another release.
>>
>>> I would like to establish a tradition where, after some final bug  
>>> fix
>>> release (e.g. for 2.5), further "mere" bug fixes are banned from the
>>> maintenance branch (and I did revert several bug fixes from the 2.4
>>> branch).
>>
>> I'm not sure I agree with this policy.  Can you elaborate on /why/  
>> you
>> want this?
>
> Because there won't typically be sufficient testing and release
> infrastructure to allow arbitrary bug fixes to be committed on the
> branch. The buildbots are turned off, and nobody tests the release
> candidate, no Windows binaries are provided - thus, chances are very
> high that a bug fix release for some very old branch will be *worse*
> than the previous release, rather than better.

Why is that qualitatively different than a security fix?  All the same  
conditions apply.

> An alternative would be to keep all infrastructure up and running,
> but that is infeasible.

Or to adopt tools that help improve reliability.  I'm not convinced  
that the buildbots really do that.  A PQM-style approach, while more  
of a pain for developers because of the serialized landings, would  
definitely improve things, and there's not nearly as much  
infrastructure involved to keep humming for old releases.  PQM isn't  
perfect, but I do believe it would help.

>> I understand that we're a volunteer organization, and that our  
>> resources
>> are limited.  I'm also wary about siphoning off those limit resources
>> right now for working on other than 2.6 and 3.0, but I'm not sure  
>> that
>> this policy really buys us much there. E.g. with this policy you'll  
>> need
>> a release cop to patrol commits and back out non-security fixes right
>> away.
>
> That's not necessary. When I made 2.3.7 and 2.4.5, I went through the
> complete log, and posted a list of patches that I wanted to revert.
> This was little effort, and I'm sure it would have been even less  
> effort
> if people had known that 2.4.x is a closed branch.

I'm glad it wasn't much effort.  Would you propose using technological  
means to close the branch?

>> It's much more work to revert such changes whenever we get around
>> to doing the release.  Seems like it could be /more/ work with this  
>> policy.
>
> It wasn't really that much work - there were little non-security
> patches, and they were easily identifiable from the commit message.
>
>> I do agree that we need to be very careful about introducing new
>> features, but I think non-security patches can be okay.
>
> They aren't, as they don't get sufficient testing.

Again, I don't think that's qualitatively much different for security  
patches.  We may manually test them, inspect them, rely on vendors to  
have tested them, but they don't go through the Q/A process we enforce  
for our active branches.

>> It's
>> demoralizing to have one's patches backed out.  Besides, we still  
>> have
>> downstream vendors that are maintaining and releasing Python 2.4;  
>> does
>> this mean they're out of luck for bug fixes or they have to roll  
>> their own?
>
> I've talked to the downstream vendors, and they really want security
> patches for a long time, above all. They are fine with maintaining  
> their
> own patches (which they do, anyway).

Would a policy of security-patches-only have any effect on vendors  
sharing fixes with us?  By that I mean, if 2.4 were open to non- 
security patches, would they be more or less willing to feed them  
upstream, where we could, if someone were motivated, port them forward?

>> We're on an 18 month release schedule, which is a long time to  
>> wait, so
>> I'm not in favor of an arbitrary date for cutting off "mere" bug  
>> fixes.
>> Rather, I'd like to see a policy (but not a promise) of supporting  
>> two
>> releases at a time.
>
> I think this requires more resources than we have - especially with
> your way of counting:
>
>> Thus, when 2.6 is released, we would stop support
>> for all but critical security fixes for 2.4, but we could (not will)
>> still release bug fixes for 2.5.  And of course, we'll support  
>> 2.6/3.0
>> while 2.7/3.1 is being developed.
>
> So that's *three* branches that we need to maintain, right: 2.5, 2.6,
> and 3.0. Once 3.1 is released, I supposed it's even *four* branches:
> 2.6, 2.7, 3.0, and 3.1. That means that every change must be
> committed/merged four times, you need to run the test suite four  
> times,
> and so on. Depending on the nature of the bug fix, you also need to
> keep the specifics of the four branches in mind.
>
> I don't think our committers will accept such a work load - which  
> means
> that some patches don't get backported (arbitrarily, depending on how
> relevant the committer views that policy).

Let me emphasize that I'm not suggesting our committers do this.  I'm  
suggesting that if a specific committer is motivated to fix a non- 
security bug in an older release, they would have to accept this  
responsibility.  Maybe it'll never happen because no one really cares  
enough.  But a policy against it would /prevent/ it even if there was  
motivation to do it.

>> Having lockstep 2.x and 3.x release complicates things a bit, but
>> because they are lockstep, I'm thinking of them more as the same  
>> release
>> rather than separate ones.
>
> I think this is an illusion. When did you last commit something to the
> trunk, and forward-ported it to the 3.0 branch? When did you last run
> "svnmerge avail"? Porting patches between 2.6 and 3.0 is anything but
> trivial.

I'll concede that it's very difficult.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSKNhKnEjvBPtnXfVAQLC1AP8D4aJqfpEVCDt2I70wbiBLX+U2AL4LzmS
B08/pfWwZ1XdCRtx9Fp0MqVuTqpaKMJXXkA3zq6gxOQW1MQOi/ubWYkUlQYc/JMz
ZZUwm+jmccc+YeD5jffFM7HDuPK0hyHmK9MaS8blwXddQBiMIeJ/8u7gGmZGVN81
4FNjnwz1c1s=
=RBUx
-----END PGP SIGNATURE-----

From barry at python.org  Thu Aug 14 01:03:26 2008
From: barry at python.org (Barry Warsaw)
Date: Wed, 13 Aug 2008 19:03:26 -0400
Subject: [python-committers] PQM?
In-Reply-To: <1218667291.22748.12.camel@fsol>
References: <4838EA2D.7060402@jcea.es> <4884581F.8010201@jcea.es>
	<bbaeab100807211116g4df70dc1o81b1075a88282c93@mail.gmail.com>
	<1BDCADF2-F6EE-4824-80BF-68CB1760CA7B@python.org>
	<loom.20080811T095014-204@post.gmane.org>
	<2F883F29-DAD8-4D4D-948D-DDAD872EB2A4@python.org>
	<6D041763-67AC-4213-AF2B-4AFBB991C699@python.org>
	<48A114EB.3090801@v.loewis.de>
	<e69d3ed20808112308n2ed1739fv3ecb79e2fa1de279@mail.gmail.com>
	<48A12D81.1040309@v.loewis.de>
	<e69d3ed20808112354t6cb1a55esbc90126b573fb18b@mail.gmail.com>
	<48A13DFA.3080504@v.loewis.de>
	<557787AE-51CD-49EB-B16F-C22F45B9F51E@python.org>
	<48A1DA1A.7090103@v.loewis.de>
	<4F0CDE78-146A-493B-BD7D-7D67291E2799@python.org>
	<1218667291.22748.12.camel@fsol>
Message-ID: <E0530C6F-0330-43E4-B134-0D24EB5AB0CF@python.org>

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

On Aug 13, 2008, at 6:41 PM, Antoine Pitrou wrote:

> Le mercredi 13 ao?t 2008 ? 18:33 -0400, Barry Warsaw a ?crit :
>> Or to adopt tools that help improve reliability.  I'm not convinced
>> that the buildbots really do that.  A PQM-style approach, while more
>> of a pain for developers because of the serialized landings, would
>> definitely improve things, and there's not nearly as much
>> infrastructure involved to keep humming for old releases.  PQM isn't
>> perfect, but I do believe it would help.
>
> What is a "PQM-style approach"?

PQM = Patch Queue Manager

Basically, it's a robot that controls commits to the trunk.  Nothing  
lands in the trunk without getting through PQM first.  PQM serializes  
changesets so that they must apply cleanly with no conflicts, and pass  
the entire test suite.  There could be other conditions, e.g. that it  
lints cleanly, has no whitespace issues, etc.

If any of the set of conditions fail, the changeset does not land.   
This means that the trunk is always in a releasable state, and we  
avoid the problems I run into all the time now, where we have red  
buildbots on or near release date.  I would dearly love to be able to  
spin a release at any time and have a high degree of confidence that  
what I'm releasing is stable.

There's a specific implementation of PQM based on the Bazaar revision  
control system, available here: https://edge.launchpad.net/pqm

PQM is not perfect, nor is it a perfect fit for us.  For example, we  
have buildbots that run on multiple platforms, while PQM runs on a  
single platform.  So a vanilla PQM could still miss changes that break  
only on a specific operating system.  It also doesn't help at all for  
bugs not covered by the test suite (well, buildbots don't help there  
either ;).

PQM also introduces delays on trunk landing because it serializes  
commits.  So when things get backed up, it might take a while for your  
branch to land on the trunk.

PQM wouldn't replace the buildbots, but it would greatly improve the  
quality of the development branches, IMO.  The buildbots would still  
be useful to ensure cross-platform quality.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSKNoP3EjvBPtnXfVAQIrdwP+I9Cj7uBl+Ux9ioDd+Xc2KXCcF0hXRqpj
z4XfUdZeWlUQdUoNspj/mzl9Q/zVz4wyTUmmDV3nH9a5qd6vGAnFvOZHLwpipDE2
NYISJYVWlYp71ljANJ/sWoywAc8Lj/AaD2l532S8RC4JPf53MNlIyB3CtIpDq315
ZMqS3RSRP10=
=5qLh
-----END PGP SIGNATURE-----

From martin at v.loewis.de  Thu Aug 14 01:33:57 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 14 Aug 2008 01:33:57 +0200
Subject: [python-committers] [Python-Dev] next beta
In-Reply-To: <4F0CDE78-146A-493B-BD7D-7D67291E2799@python.org>
References: <4838EA2D.7060402@jcea.es> <4884581F.8010201@jcea.es>	
	<bbaeab100807211116g4df70dc1o81b1075a88282c93@mail.gmail.com>	
	<1BDCADF2-F6EE-4824-80BF-68CB1760CA7B@python.org>	
	<loom.20080811T095014-204@post.gmane.org>	
	<2F883F29-DAD8-4D4D-948D-DDAD872EB2A4@python.org>	
	<6D041763-67AC-4213-AF2B-4AFBB991C699@python.org>	
	<48A114EB.3090801@v.loewis.de>	
	<e69d3ed20808112308n2ed1739fv3ecb79e2fa1de279@mail.gmail.com>	
	<48A12D81.1040309@v.loewis.de>
	<e69d3ed20808112354t6cb1a55esbc90126b573fb18b@mail.gmail.com>
	<48A13DFA.3080504@v.loewis.de>
	<557787AE-51CD-49EB-B16F-C22F45B9F51E@python.org>
	<48A1DA1A.7090103@v.loewis.de>
	<4F0CDE78-146A-493B-BD7D-7D67291E2799@python.org>
Message-ID: <48A36F65.1060301@v.loewis.de>

>> Because there won't typically be sufficient testing and release
>> infrastructure to allow arbitrary bug fixes to be committed on the
>> branch. The buildbots are turned off, and nobody tests the release
>> candidate, no Windows binaries are provided - thus, chances are very
>> high that a bug fix release for some very old branch will be *worse*
>> than the previous release, rather than better.
> 
> Why is that qualitatively different than a security fix?  All the same
> conditions apply.

No. The problem being fixed is completely different. For a security fix,
it is typically fairly obvious what the bug being fixed is (in
particular, if you look at the recent ones dealing with overflows): the
interpreter crashes without the patch, and stops crashing (but raises
an exception instead) with the patch.

For regular bug fixes, it is much more difficult to see whether the
behavior being changed was a bug. They typically "merely" change the
behavior A to behavior B, along with a claim that behavior A is
a bug, and behavior B is correct. Even if that is true, there is still
a chance that applications relied on behavior A, and break. OTOH, for
an interpreter crash, it is highly unlikely that existing applications
rely on the crash.

For example, in the 2.4 branch, among the patches I rolled back, was
r53001. This adds string.strip to the lookup of logging handlers.
It might be "better" to do that (and perhaps even correspond with the
documentation), but still, it might break applications which had
leading or trailing spaces in their handlers names.

>> That's not necessary. When I made 2.3.7 and 2.4.5, I went through the
>> complete log, and posted a list of patches that I wanted to revert.
>> This was little effort, and I'm sure it would have been even less effort
>> if people had known that 2.4.x is a closed branch.
> 
> I'm glad it wasn't much effort.  Would you propose using technological
> means to close the branch?

They are still open for security patches (well, 2.4 is; under my
proposed policy, 2.3 isn't anymore). If people think it's desirable,
we could rename the branch, or we could enforce a certain keyword
(e.g. "security") in the commit messages.

> Again, I don't think that's qualitatively much different for security
> patches.  We may manually test them, inspect them, rely on vendors to
> have tested them, but they don't go through the Q/A process we enforce
> for our active branches.

Due to the reliance on inspection, it is *particularly* important that
there are only few of them, and that those are all local.

> Would a policy of security-patches-only have any effect on vendors
> sharing fixes with us?  By that I mean, if 2.4 were open to non-security
> patches, would they be more or less willing to feed them upstream, where
> we could, if someone were motivated, port them forward?

I do think that vendors will continue to provide patches. They want to
get rid of them to reduce their overhead, eventually, and it doesn't
really matter that much that they get rid of them for the current
branch (as they have done all the hard work there already). Efforts
grow when you need to forward-port it, in which case you do want to
contribute it upstream (in the hope of at least partially offloading
the effort to a regular Python contributor).

> Let me emphasize that I'm not suggesting our committers do this.  I'm
> suggesting that if a specific committer is motivated to fix a
> non-security bug in an older release, they would have to accept this
> responsibility.  Maybe it'll never happen because no one really cares
> enough.  But a policy against it would /prevent/ it even if there was
> motivation to do it.

I don't like the arbitrariness that this will produce.

>> I think this is an illusion. When did you last commit something to the
>> trunk, and forward-ported it to the 3.0 branch? When did you last run
>> "svnmerge avail"? Porting patches between 2.6 and 3.0 is anything but
>> trivial.
> 
> I'll concede that it's very difficult.

Indeed. I just added s* to both 2.6 and 3.0, and it took me two days
to port it from 2.6 to 3.0 (just because 3.0 was using the buffer
interface in so many more places).

Regards,
Martin

From janssen at parc.com  Thu Aug 14 01:52:21 2008
From: janssen at parc.com (Bill Janssen)
Date: Wed, 13 Aug 2008 16:52:21 PDT
Subject: [python-committers] PQM?
In-Reply-To: <E0530C6F-0330-43E4-B134-0D24EB5AB0CF@python.org> 
References: <4838EA2D.7060402@jcea.es> <4884581F.8010201@jcea.es>
	<bbaeab100807211116g4df70dc1o81b1075a88282c93@mail.gmail.com>
	<1BDCADF2-F6EE-4824-80BF-68CB1760CA7B@python.org>
	<loom.20080811T095014-204@post.gmane.org>
	<2F883F29-DAD8-4D4D-948D-DDAD872EB2A4@python.org>
	<6D041763-67AC-4213-AF2B-4AFBB991C699@python.org>
	<48A114EB.3090801@v.loewis.de>
	<e69d3ed20808112308n2ed1739fv3ecb79e2fa1de279@mail.gmail.com>
	<48A12D81.1040309@v.loewis.de>
	<e69d3ed20808112354t6cb1a55esbc90126b573fb18b@mail.gmail.com>
	<48A13DFA.3080504@v.loewis.de>
	<557787AE-51CD-49EB-B16F-C22F45B9F51E@python.org>
	<48A1DA1A.7090103@v.loewis.de>
	<4F0CDE78-146A-493B-BD7D-7D67291E2799@python.org>
	<1218667291.22748.12.camel@fsol>
	<E0530C6F-0330-43E4-B134-0D24EB5AB0CF@python.org>
Message-ID: <08Aug13.165230pdt."58698"@synergy1.parc.xerox.com>

> PQM serializes changesets so that they must apply cleanly with no
> conflicts, and pass the entire test suite.

What platform would it run the test suite on?  Presumably the same one
I tested on before I submitted the patch :-).

I think this works if you're a Linux development shop, but perhaps
not as well for Python.

Bill

From brett at python.org  Thu Aug 14 04:40:16 2008
From: brett at python.org (Brett Cannon)
Date: Wed, 13 Aug 2008 19:40:16 -0700
Subject: [python-committers] [Python-Dev] next beta
In-Reply-To: <4F0CDE78-146A-493B-BD7D-7D67291E2799@python.org>
References: <4838EA2D.7060402@jcea.es>
	<6D041763-67AC-4213-AF2B-4AFBB991C699@python.org>
	<48A114EB.3090801@v.loewis.de>
	<e69d3ed20808112308n2ed1739fv3ecb79e2fa1de279@mail.gmail.com>
	<48A12D81.1040309@v.loewis.de>
	<e69d3ed20808112354t6cb1a55esbc90126b573fb18b@mail.gmail.com>
	<48A13DFA.3080504@v.loewis.de>
	<557787AE-51CD-49EB-B16F-C22F45B9F51E@python.org>
	<48A1DA1A.7090103@v.loewis.de>
	<4F0CDE78-146A-493B-BD7D-7D67291E2799@python.org>
Message-ID: <bbaeab100808131940m56e189a5uf077dff3b5957dec@mail.gmail.com>

On Wed, Aug 13, 2008 at 3:33 PM, Barry Warsaw <barry at python.org> wrote:
[SNIP]
>> An alternative would be to keep all infrastructure up and running,
>> but that is infeasible.
>
> Or to adopt tools that help improve reliability.  I'm not convinced that the
> buildbots really do that.  A PQM-style approach, while more of a pain for
> developers because of the serialized landings, would definitely improve
> things, and there's not nearly as much infrastructure involved to keep
> humming for old releases.  PQM isn't perfect, but I do believe it would
> help.
>

What is a "PQM-style approach" to releases?

-Brett

From brett at python.org  Thu Aug 14 04:49:14 2008
From: brett at python.org (Brett Cannon)
Date: Wed, 13 Aug 2008 19:49:14 -0700
Subject: [python-committers] PQM?
In-Reply-To: <E0530C6F-0330-43E4-B134-0D24EB5AB0CF@python.org>
References: <4838EA2D.7060402@jcea.es>
	<e69d3ed20808112308n2ed1739fv3ecb79e2fa1de279@mail.gmail.com>
	<48A12D81.1040309@v.loewis.de>
	<e69d3ed20808112354t6cb1a55esbc90126b573fb18b@mail.gmail.com>
	<48A13DFA.3080504@v.loewis.de>
	<557787AE-51CD-49EB-B16F-C22F45B9F51E@python.org>
	<48A1DA1A.7090103@v.loewis.de>
	<4F0CDE78-146A-493B-BD7D-7D67291E2799@python.org>
	<1218667291.22748.12.camel@fsol>
	<E0530C6F-0330-43E4-B134-0D24EB5AB0CF@python.org>
Message-ID: <bbaeab100808131949r4693814eibf12a0dcd9bb78ad@mail.gmail.com>

On Wed, Aug 13, 2008 at 4:03 PM, Barry Warsaw <barry at python.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Aug 13, 2008, at 6:41 PM, Antoine Pitrou wrote:
>
>> Le mercredi 13 ao?t 2008 ? 18:33 -0400, Barry Warsaw a ?crit :
>>>
>>> Or to adopt tools that help improve reliability.  I'm not convinced
>>> that the buildbots really do that.  A PQM-style approach, while more
>>> of a pain for developers because of the serialized landings, would
>>> definitely improve things, and there's not nearly as much
>>> infrastructure involved to keep humming for old releases.  PQM isn't
>>> perfect, but I do believe it would help.
>>
>> What is a "PQM-style approach"?
>
> PQM = Patch Queue Manager
>
> Basically, it's a robot that controls commits to the trunk.  Nothing lands
> in the trunk without getting through PQM first.  PQM serializes changesets
> so that they must apply cleanly with no conflicts, and pass the entire test
> suite.  There could be other conditions, e.g. that it lints cleanly, has no
> whitespace issues, etc.
>

Ah, OK.

> If any of the set of conditions fail, the changeset does not land.  This
> means that the trunk is always in a releasable state, and we avoid the
> problems I run into all the time now, where we have red buildbots on or near
> release date.  I would dearly love to be able to spin a release at any time
> and have a high degree of confidence that what I'm releasing is stable.
>

Well, it would definitely catch those changes that manage to break ALL
the buildbots, but those that only break on the platforms that the
developer is not on might just cause pain.

> There's a specific implementation of PQM based on the Bazaar revision
> control system, available here: https://edge.launchpad.net/pqm
>

Why am I not surprised that bzr has support for something you are suggesting? =)

> PQM is not perfect, nor is it a perfect fit for us.  For example, we have
> buildbots that run on multiple platforms, while PQM runs on a single
> platform.  So a vanilla PQM could still miss changes that break only on a
> specific operating system.  It also doesn't help at all for bugs not covered
> by the test suite (well, buildbots don't help there either ;).
>
> PQM also introduces delays on trunk landing because it serializes commits.
>  So when things get backed up, it might take a while for your branch to land
> on the trunk.
>

There is also the shift in development style to larger patch sets
(assuming your version control system supports patch sets) instead of
a lot of incremental commits to the trunk since you might end up with
a cascading failure of your commits if you were dependent on an
earlier one fails and thus all your subsequent checkins will be
rejected.

> PQM wouldn't replace the buildbots, but it would greatly improve the quality
> of the development branches, IMO.  The buildbots would still be useful to
> ensure cross-platform quality.

Well, another option is to flesh out ``make check`` such that it runs
more sanity checks and makes sure the entire test suite is run and
passed before a commit is done, basically doing what you are
suggesting, but on a local level.

-Brett

From musiccomposition at gmail.com  Thu Aug 14 04:51:59 2008
From: musiccomposition at gmail.com (Benjamin Peterson)
Date: Wed, 13 Aug 2008 20:51:59 -0600
Subject: [python-committers] PQM?
In-Reply-To: <bbaeab100808131949r4693814eibf12a0dcd9bb78ad@mail.gmail.com>
References: <4838EA2D.7060402@jcea.es> <48A12D81.1040309@v.loewis.de>
	<e69d3ed20808112354t6cb1a55esbc90126b573fb18b@mail.gmail.com>
	<48A13DFA.3080504@v.loewis.de>
	<557787AE-51CD-49EB-B16F-C22F45B9F51E@python.org>
	<48A1DA1A.7090103@v.loewis.de>
	<4F0CDE78-146A-493B-BD7D-7D67291E2799@python.org>
	<1218667291.22748.12.camel@fsol>
	<E0530C6F-0330-43E4-B134-0D24EB5AB0CF@python.org>
	<bbaeab100808131949r4693814eibf12a0dcd9bb78ad@mail.gmail.com>
Message-ID: <1afaf6160808131951ra66e4e8r3357be45bd760e66@mail.gmail.com>

On Wed, Aug 13, 2008 at 8:49 PM, Brett Cannon <brett at python.org> wrote:
> Well, another option is to flesh out ``make check`` such that it runs
> more sanity checks and makes sure the entire test suite is run and
> passed before a commit is done, basically doing what you are
> suggesting, but on a local level.

In my "testing" branch, I have added support for this in "make check".

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



-- 
Cheers,
Benjamin Peterson
"There's no place like 127.0.0.1."

From solipsis at pitrou.net  Thu Aug 14 00:41:31 2008
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Thu, 14 Aug 2008 00:41:31 +0200
Subject: [python-committers] PQM?
In-Reply-To: <4F0CDE78-146A-493B-BD7D-7D67291E2799@python.org>
References: <4838EA2D.7060402@jcea.es> <4884581F.8010201@jcea.es>
	<bbaeab100807211116g4df70dc1o81b1075a88282c93@mail.gmail.com>
	<1BDCADF2-F6EE-4824-80BF-68CB1760CA7B@python.org>
	<loom.20080811T095014-204@post.gmane.org>
	<2F883F29-DAD8-4D4D-948D-DDAD872EB2A4@python.org>
	<6D041763-67AC-4213-AF2B-4AFBB991C699@python.org>
	<48A114EB.3090801@v.loewis.de>
	<e69d3ed20808112308n2ed1739fv3ecb79e2fa1de279@mail.gmail.com>
	<48A12D81.1040309@v.loewis.de>
	<e69d3ed20808112354t6cb1a55esbc90126b573fb18b@mail.gmail.com>
	<48A13DFA.3080504@v.loewis.de>
	<557787AE-51CD-49EB-B16F-C22F45B9F51E@python.org>
	<48A1DA1A.7090103@v.loewis.de>
	<4F0CDE78-146A-493B-BD7D-7D67291E2799@python.org>
Message-ID: <1218667291.22748.12.camel@fsol>

?Le mercredi 13 ao?t 2008 ? 18:33 -0400, Barry Warsaw a ?crit : 
> Or to adopt tools that help improve reliability.  I'm not convinced  
> that the buildbots really do that.  A PQM-style approach, while more  
> of a pain for developers because of the serialized landings, would  
> definitely improve things, and there's not nearly as much  
> infrastructure involved to keep humming for old releases.  PQM isn't  
> perfect, but I do believe it would help.

What is a "PQM-style approach"?



From christian at cheimes.de  Thu Aug 14 03:12:09 2008
From: christian at cheimes.de (Christian Heimes)
Date: Thu, 14 Aug 2008 03:12:09 +0200
Subject: [python-committers] PQM?
In-Reply-To: <E0530C6F-0330-43E4-B134-0D24EB5AB0CF@python.org>
References: <4838EA2D.7060402@jcea.es>
	<4884581F.8010201@jcea.es>	<bbaeab100807211116g4df70dc1o81b1075a88282c93@mail.gmail.com>	<1BDCADF2-F6EE-4824-80BF-68CB1760CA7B@python.org>	<loom.20080811T095014-204@post.gmane.org>	<2F883F29-DAD8-4D4D-948D-DDAD872EB2A4@python.org>	<6D041763-67AC-4213-AF2B-4AFBB991C699@python.org>	<48A114EB.3090801@v.loewis.de>	<e69d3ed20808112308n2ed1739fv3ecb79e2fa1de279@mail.gmail.com>	<48A12D81.1040309@v.loewis.de>	<e69d3ed20808112354t6cb1a55esbc90126b573fb18b@mail.gmail.com>	<48A13DFA.3080504@v.loewis.de>	<557787AE-51CD-49EB-B16F-C22F45B9F51E@python.org>	<48A1DA1A.7090103@v.loewis.de>	<4F0CDE78-146A-493B-BD7D-7D67291E2799@python.org>	<1218667291.22748.12.camel@fsol>
	<E0530C6F-0330-43E4-B134-0D24EB5AB0CF@python.org>
Message-ID: <48A38669.4050204@cheimes.de>

Barry Warsaw wrote:
> PQM = Patch Queue Manager
> 
> Basically, it's a robot that controls commits to the trunk.  Nothing 
> lands in the trunk without getting through PQM first.  PQM serializes 
> changesets so that they must apply cleanly with no conflicts, and pass 
> the entire test suite.  There could be other conditions, e.g. that it 
> lints cleanly, has no whitespace issues, etc.

Personally I'm totally against any kind of tool like PQM for general 
development. Issues due erroneous check-ins are a social problem. I 
strongly believe that social problems can't be solved by a system like 
PQM. PQM may work for companies or projects with a large developer group 
but not for Python.
I fear it'd cause more problems than it's worth. There are valid reasons 
for checking in failing unit tests. For example a developer spots a 
problem but isn't able to fix on his own. Any fancy system that delays 
or prohibits check-ins is going to slow us down.

In my opinion a system like PQM should only be used when a RC or final 
release is immanent. I can picture the usefulness of PQM during the last 
few weeks before a release.

I'd rather see the man power put into better testing facilities than 
into a tool like PQM. If you are worried about the stability of the 
trunk I'd rather suggest a change of our code of conduct. For example 
every change of code, which isn't just a minor change, must be applied 
to a new branch and reviewed by a second developer before it's applied 
to the trunk. I think development inside branches and peer reviewing 
yield better results than a machine that rules over developers.

Christian, who still thinks (hopes) that the human mind outperforms 
machines when it comes down to important and complex decisions.

From barry at python.org  Thu Aug 14 06:14:07 2008
From: barry at python.org (Barry Warsaw)
Date: Thu, 14 Aug 2008 00:14:07 -0400
Subject: [python-committers] [Python-Dev] next beta
In-Reply-To: <48A36F65.1060301@v.loewis.de>
References: <4838EA2D.7060402@jcea.es> <4884581F.8010201@jcea.es>	
	<bbaeab100807211116g4df70dc1o81b1075a88282c93@mail.gmail.com>	
	<1BDCADF2-F6EE-4824-80BF-68CB1760CA7B@python.org>	
	<loom.20080811T095014-204@post.gmane.org>	
	<2F883F29-DAD8-4D4D-948D-DDAD872EB2A4@python.org>	
	<6D041763-67AC-4213-AF2B-4AFBB991C699@python.org>	
	<48A114EB.3090801@v.loewis.de>	
	<e69d3ed20808112308n2ed1739fv3ecb79e2fa1de279@mail.gmail.com>	
	<48A12D81.1040309@v.loewis.de>
	<e69d3ed20808112354t6cb1a55esbc90126b573fb18b@mail.gmail.com>
	<48A13DFA.3080504@v.loewis.de>
	<557787AE-51CD-49EB-B16F-C22F45B9F51E@python.org>
	<48A1DA1A.7090103@v.loewis.de>
	<4F0CDE78-146A-493B-BD7D-7D67291E2799@python.org>
	<48A36F65.1060301@v.loewis.de>
Message-ID: <81550766-7ABA-489D-AEE0-F1350C7F2E55@python.org>

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

On Aug 13, 2008, at 7:33 PM, Martin v. L?wis wrote:

>>> Because there won't typically be sufficient testing and release
>>> infrastructure to allow arbitrary bug fixes to be committed on the
>>> branch. The buildbots are turned off, and nobody tests the release
>>> candidate, no Windows binaries are provided - thus, chances are very
>>> high that a bug fix release for some very old branch will be *worse*
>>> than the previous release, rather than better.
>>
>> Why is that qualitatively different than a security fix?  All the  
>> same
>> conditions apply.
>
> No. The problem being fixed is completely different. For a security  
> fix,
> it is typically fairly obvious what the bug being fixed is (in
> particular, if you look at the recent ones dealing with overflows):  
> the
> interpreter crashes without the patch, and stops crashing (but raises
> an exception instead) with the patch.

That's true of a certain class of bugs, probably mostly in the C  
code.  I think potential security bugs in Python code will be closer  
to "regular" bug fixes.

>> I'm glad it wasn't much effort.  Would you propose using  
>> technological
>> means to close the branch?
>
> They are still open for security patches (well, 2.4 is; under my
> proposed policy, 2.3 isn't anymore). If people think it's desirable,
> we could rename the branch, or we could enforce a certain keyword
> (e.g. "security") in the commit messages.

I was thinking about preventing commits on the branch.  Most security  
fixes of the type you describe come in through the psrt, and they may  
even be embargoed.  For a closed branch, you'd open it for the  
security patches when the embargo is lifted, make the commits, then  
close it again.  That would at least be a very strong clue that the  
branch is closed :).

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSKOxEHEjvBPtnXfVAQLnDwP/SxtyECt++5uvFKdwIkop7xP2tyLy7IBW
sigKb7WOvVH/Iiz16xf7zdEuXqsV1h59QvPDCzwk8/6VTggjbfhZ9qt+PdwlClzL
cbc1JFI0DSDQ8tVOiPtJhsvvAhXMAlZI5FmMRxp77Cc3y9JUwczxzIP2fXw4IvUQ
K6WO3bLbY5s=
=USCq
-----END PGP SIGNATURE-----

From guido at python.org  Thu Aug 14 06:16:39 2008
From: guido at python.org (Guido van Rossum)
Date: Wed, 13 Aug 2008 21:16:39 -0700
Subject: [python-committers] PQM?
In-Reply-To: <48A38669.4050204@cheimes.de>
References: <4838EA2D.7060402@jcea.es> <48A12D81.1040309@v.loewis.de>
	<e69d3ed20808112354t6cb1a55esbc90126b573fb18b@mail.gmail.com>
	<48A13DFA.3080504@v.loewis.de>
	<557787AE-51CD-49EB-B16F-C22F45B9F51E@python.org>
	<48A1DA1A.7090103@v.loewis.de>
	<4F0CDE78-146A-493B-BD7D-7D67291E2799@python.org>
	<1218667291.22748.12.camel@fsol>
	<E0530C6F-0330-43E4-B134-0D24EB5AB0CF@python.org>
	<48A38669.4050204@cheimes.de>
Message-ID: <ca471dc20808132116v6cec6150kdb06d3d19904f7ff@mail.gmail.com>

On Wed, Aug 13, 2008 at 6:12 PM, Christian Heimes <christian at cheimes.de> wrote:
> Barry Warsaw wrote:
>>
>> PQM = Patch Queue Manager
>>
>> Basically, it's a robot that controls commits to the trunk.  Nothing lands
>> in the trunk without getting through PQM first.  PQM serializes changesets
>> so that they must apply cleanly with no conflicts, and pass the entire test
>> suite.  There could be other conditions, e.g. that it lints cleanly, has no
>> whitespace issues, etc.
>
> Personally I'm totally against any kind of tool like PQM for general
> development. Issues due erroneous check-ins are a social problem. I strongly
> believe that social problems can't be solved by a system like PQM. PQM may
> work for companies or projects with a large developer group but not for
> Python.
> I fear it'd cause more problems than it's worth. There are valid reasons for
> checking in failing unit tests. For example a developer spots a problem but
> isn't able to fix on his own. Any fancy system that delays or prohibits
> check-ins is going to slow us down.
>
> In my opinion a system like PQM should only be used when a RC or final
> release is immanent. I can picture the usefulness of PQM during the last few
> weeks before a release.
>
> I'd rather see the man power put into better testing facilities than into a
> tool like PQM. If you are worried about the stability of the trunk I'd
> rather suggest a change of our code of conduct. For example every change of
> code, which isn't just a minor change, must be applied to a new branch and
> reviewed by a second developer before it's applied to the trunk. I think
> development inside branches and peer reviewing yield better results than a
> machine that rules over developers.
>
> Christian, who still thinks (hopes) that the human mind outperforms machines
> when it comes down to important and complex decisions.

[Hey Christian, welcome back! (It seems we hadn't heard much from you
for a while...)]

I don't have experience with PQM or something like it, but I suspect
it doesn't scale, and the buildbots are a better approach, because
they handle multiple platforms.

I do think that better tools can help us some -- while you can't solve
every social problem with tools, the reverse isn't true either --
sometimes it *is* possible to solve (or at least alleviate) social
problems with tools.

As long as we're touting tools or processes that we have experience
with, Google uses a combination of tools. One tool is similar to the
buildbots, running tests *after* stuff has been checked in. A feature
that buildbot is missing is that it tries to figure which checkin is
responsible for a particular failure, and mails both the author of
that change and the owner of the code (if different).

Another tool that helps code quality tremendously is mandatory peer
reviews of all code before checkin. Call me biased because I wrote the
first version of the tool that most Googlers today use for peer
reviews (Collin Winter now runs that show) and also open-sourced a
similar tool (Rietveld, http://codereview.appspot.com) that works with
Subversion. But I didn't set the policy of mandatory pre-checkin peer
reviews -- Google had that policy for years before, and other tools
had already been written.

I particularly like the peer review policy because it is actually
largely a *social* solution: code review is a very social process, the
tools are secondary. By peer-reviewing all code before it goes in, not
only do you catch many problems in an earlier stage than otherwise
possible, but it also ensures that there are always at least two
developers who know and understand the changes (or new code --
everything gets reviewed, even doc changes and changes to build
files). Plus, it improves relationships between developers: if
yesterday I found a bug in your code during peer review, today I may
be more susceptible to you pointing out bugs in *my* code. This is a
lot better than finding bugs during debugging sessions: once you've
spent an hour tracking down a nasty bug you're much more likely to
have a low opinion of whoever checked in the buggy code, and you're
less likely to trust their judgment of your own code.

Anyway, if we're going to change policies around submitting code, I
would much rather see peer review become a habit than adopt a tool
like PQM.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From barry at python.org  Thu Aug 14 06:16:48 2008
From: barry at python.org (Barry Warsaw)
Date: Thu, 14 Aug 2008 00:16:48 -0400
Subject: [python-committers] PQM?
In-Reply-To: <08Aug13.165230pdt."58698"@synergy1.parc.xerox.com>
References: <4838EA2D.7060402@jcea.es> <4884581F.8010201@jcea.es>
	<bbaeab100807211116g4df70dc1o81b1075a88282c93@mail.gmail.com>
	<1BDCADF2-F6EE-4824-80BF-68CB1760CA7B@python.org>
	<loom.20080811T095014-204@post.gmane.org>
	<2F883F29-DAD8-4D4D-948D-DDAD872EB2A4@python.org>
	<6D041763-67AC-4213-AF2B-4AFBB991C699@python.org>
	<48A114EB.3090801@v.loewis.de>
	<e69d3ed20808112308n2ed1739fv3ecb79e2fa1de279@mail.gmail.com>
	<48A12D81.1040309@v.loewis.de>
	<e69d3ed20808112354t6cb1a55esbc90126b573fb18b@mail.gmail.com>
	<48A13DFA.3080504@v.loewis.de>
	<557787AE-51CD-49EB-B16F-C22F45B9F51E@python.org>
	<48A1DA1A.7090103@v.loewis.de>
	<4F0CDE78-146A-493B-BD7D-7D67291E2799@python.org>
	<1218667291.22748.12.camel@fsol>
	<E0530C6F-0330-43E4-B134-0D24EB5AB0CF@python.org>
	<08Aug13.165230pdt."58698"@synergy1.parc.xerox.com>
Message-ID: <5202BC6E-35F4-49E8-989F-8A7D4D7C0AFC@python.org>

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

On Aug 13, 2008, at 7:52 PM, Bill Janssen wrote:

>> PQM serializes changesets so that they must apply cleanly with no
>> conflicts, and pass the entire test suite.
>
> What platform would it run the test suite on?  Presumably the same one
> I tested on before I submitted the patch :-).

I think we'd just have to pick one.  It would probably be a *nix based  
system.

> I think this works if you're a Linux development shop, but perhaps
> not as well for Python.

It would still solve a problem we have today, which is that the  
release branch is very often broken when the time comes to cut a  
release.  We've had to delay several releases because of red buildbots  
or failing tests across multiple platforms.  Even having the branch  
always releasable on <pick one> Linux would be a big improvement.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iQCUAwUBSKOxsXEjvBPtnXfVAQLjdgP3RbRUTJybYA2EiSLcP8elEgsZAnF1Ej+b
pPmRxghXgszla/wDIhlBqP2kmwPefe9svpG7bknwvgCVdk6cf0KdkGlhrFqVUAsm
iYle1QEB43R7AleuF84rW3ECYriww7wTUtRjTzxGP7SMX+atEUY/ryF5rwaue313
XrrEYtXitQ==
=U4fN
-----END PGP SIGNATURE-----

From barry at python.org  Thu Aug 14 06:35:28 2008
From: barry at python.org (Barry Warsaw)
Date: Thu, 14 Aug 2008 00:35:28 -0400
Subject: [python-committers] PQM?
In-Reply-To: <48A38669.4050204@cheimes.de>
References: <4838EA2D.7060402@jcea.es>
	<4884581F.8010201@jcea.es>	<bbaeab100807211116g4df70dc1o81b1075a88282c93@mail.gmail.com>	<1BDCADF2-F6EE-4824-80BF-68CB1760CA7B@python.org>	<loom.20080811T095014-204@post.gmane.org>	<2F883F29-DAD8-4D4D-948D-DDAD872EB2A4@python.org>	<6D041763-67AC-4213-AF2B-4AFBB991C699@python.org>	<48A114EB.3090801@v.loewis.de>	<e69d3ed20808112308n2ed1739fv3ecb79e2fa1de279@mail.gmail.com>	<48A12D81.1040309@v.loewis.de>	<e69d3ed20808112354t6cb1a55esbc90126b573fb18b@mail.gmail.com>	<48A13DFA.3080504@v.loewis.de>	<557787AE-51CD-49EB-B16F-C22F45B9F51E@python.org>	<48A1DA1A.7090103@v.loewis.de>	<4F0CDE78-146A-493B-BD7D-7D67291E2799@python.org>	<1218667291.22748.12.camel@fsol>
	<E0530C6F-0330-43E4-B134-0D24EB5AB0CF@python.org>
	<48A38669.4050204@cheimes.de>
Message-ID: <8D25F11C-2E17-44F9-932E-E8E2831EAF47@python.org>

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

On Aug 13, 2008, at 9:12 PM, Christian Heimes wrote:

> Barry Warsaw wrote:
>> PQM = Patch Queue Manager
>> Basically, it's a robot that controls commits to the trunk.   
>> Nothing lands in the trunk without getting through PQM first.  PQM  
>> serializes changesets so that they must apply cleanly with no  
>> conflicts, and pass the entire test suite.  There could be other  
>> conditions, e.g. that it lints cleanly, has no whitespace issues,  
>> etc.
>
> Personally I'm totally against any kind of tool like PQM for general  
> development. Issues due erroneous check-ins are a social problem. I  
> strongly believe that social problems can't be solved by a system  
> like PQM.

Unfortunately, they're not being solved without PQM either!  Really,  
we've had to delay releases several times because the branches were  
broken across multiple operating systems.  Pleading on the mailing  
lists doesn't help.  Hanging out on irc doesn't help.  Having  
Benjamin, Georg, and others kicking ass on #python-dev the day of a  
release, is great, but it's also asking a lot of them.

> PQM may work for companies or projects with a large developer group  
> but not for Python.
> I fear it'd cause more problems than it's worth. There are valid  
> reasons for checking in failing unit tests. For example a developer  
> spots a problem but isn't able to fix on his own. Any fancy system  
> that delays or prohibits check-ins is going to slow us down.

That's what branches are for.  I really strongly feel that the  
mainlines (by which I mean the branches we cut releases from) should  
always be in a releasable state.  We should never be committing broken  
tests to these mainlines.  If you spot a problem you can't fix, create  
a branch and commit the broken test there, and ask for help with that  
branch.  The mainline isn't (IMHO) the place for that.

You're right that it will slow us down, but only on the mainline.   
That's a good thing, especially if it buys you high quality.

> In my opinion a system like PQM should only be used when a RC or  
> final release is immanent. I can picture the usefulness of PQM  
> during the last few weeks before a release.

We should be using the same quality assurance early in the cycle that  
we do late in the cycle.  Realistically, we're never going to switch  
to something different when we get to RC.

> I'd rather see the man power put into better testing facilities than  
> into a tool like PQM. If you are worried about the stability of the  
> trunk I'd rather suggest a change of our code of conduct. For  
> example every change of code, which isn't just a minor change, must  
> be applied to a new branch and reviewed by a second developer before  
> it's applied to the trunk. I think development inside branches and  
> peer reviewing yield better results than a machine that rules over  
> developers.

These are good policies to adopt.  I know of many projects that  
require one or two positive code reviews for branches to land in the  
mainline.  Code reviews and PQM augment each other though, they don't  
replace each other.  We're all human and code reviews will never be  
perfect.  Some changes have non-local or unexpected effects that only  
the test suite will catch.  Maybe the test pass on your machine  
because of something in your environment that breaks in the PQM  
"ideal" environment.

> Christian, who still thinks (hopes) that the human mind outperforms  
> machines when it comes down to important and complex decisions.

It's not us vs. them.  I want the machines to do the crappy grunt work  
so us humans can do what we do best, being creative and having  
fun :).  Begging people to fix broken buildbots on release day is  
neither.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSKO2EnEjvBPtnXfVAQIkzwP/cRwyLdkl27NoB3RYoWHzjv17EqeB+1Ha
sjlZ9cuYtIZG3j7YHd11BoUcpbS5ZIUHq1J9PTVdUGrqNRAdCYIZuppM2XSE95ir
lNj2VSZ0th6g0NeIcPpMTzdNOxp+OJ/np0U+k7zKJOoJl1+HopGJg3+LsO6h/XRs
Ysg1yN9BMAY=
=D6Zz
-----END PGP SIGNATURE-----

From barry at python.org  Thu Aug 14 06:42:06 2008
From: barry at python.org (Barry Warsaw)
Date: Thu, 14 Aug 2008 00:42:06 -0400
Subject: [python-committers] PQM?
In-Reply-To: <bbaeab100808131949r4693814eibf12a0dcd9bb78ad@mail.gmail.com>
References: <4838EA2D.7060402@jcea.es>
	<e69d3ed20808112308n2ed1739fv3ecb79e2fa1de279@mail.gmail.com>
	<48A12D81.1040309@v.loewis.de>
	<e69d3ed20808112354t6cb1a55esbc90126b573fb18b@mail.gmail.com>
	<48A13DFA.3080504@v.loewis.de>
	<557787AE-51CD-49EB-B16F-C22F45B9F51E@python.org>
	<48A1DA1A.7090103@v.loewis.de>
	<4F0CDE78-146A-493B-BD7D-7D67291E2799@python.org>
	<1218667291.22748.12.camel@fsol>
	<E0530C6F-0330-43E4-B134-0D24EB5AB0CF@python.org>
	<bbaeab100808131949r4693814eibf12a0dcd9bb78ad@mail.gmail.com>
Message-ID: <2F9A07FC-8DCC-46B9-A89D-412ABBF7BAE3@python.org>

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

On Aug 13, 2008, at 10:49 PM, Brett Cannon wrote:

>> If any of the set of conditions fail, the changeset does not land.   
>> This
>> means that the trunk is always in a releasable state, and we avoid  
>> the
>> problems I run into all the time now, where we have red buildbots  
>> on or near
>> release date.  I would dearly love to be able to spin a release at  
>> any time
>> and have a high degree of confidence that what I'm releasing is  
>> stable.
>>
> Well, it would definitely catch those changes that manage to break ALL
> the buildbots, but those that only break on the platforms that the
> developer is not on might just cause pain.

That's a downside of PQM, but still, someone's gotta fix the pain.   
Ideally, it would be the developer who committed the broken change.   
The problem of not having access to all the platforms, or not being  
able to debug problems on those platforms is a different issue.

>> There's a specific implementation of PQM based on the Bazaar revision
>> control system, available here: https://edge.launchpad.net/pqm
>>
>
> Why am I not surprised that bzr has support for something you are  
> suggesting? =)

Hey, a good tool is a good tool. :)  But really, I think the process  
is the important thing, then find the tools that make that process easy.

>> PQM is not perfect, nor is it a perfect fit for us.  For example,  
>> we have
>> buildbots that run on multiple platforms, while PQM runs on a single
>> platform.  So a vanilla PQM could still miss changes that break  
>> only on a
>> specific operating system.  It also doesn't help at all for bugs  
>> not covered
>> by the test suite (well, buildbots don't help there either ;).
>>
>> PQM also introduces delays on trunk landing because it serializes  
>> commits.
>> So when things get backed up, it might take a while for your branch  
>> to land
>> on the trunk.
>>
>
> There is also the shift in development style to larger patch sets
> (assuming your version control system supports patch sets) instead of
> a lot of incremental commits to the trunk since you might end up with
> a cascading failure of your commits if you were dependent on an
> earlier one fails and thus all your subsequent checkins will be
> rejected.

Yep.  Figure out what you want, then find the tools that fit. :)

>> PQM wouldn't replace the buildbots, but it would greatly improve  
>> the quality
>> of the development branches, IMO.  The buildbots would still be  
>> useful to
>> ensure cross-platform quality.
>
> Well, another option is to flesh out ``make check`` such that it runs
> more sanity checks and makes sure the entire test suite is run and
> passed before a commit is done, basically doing what you are
> suggesting, but on a local level.

Hook that into svn commit so that you /have/ to run it, and maybe you  
can convince me. :)

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSKO3nnEjvBPtnXfVAQKMbQP/XSVQ5ACG9JXrl30Jfodg2anrIPYcWjyb
+JCqs0Bbgy6vqeI3h0g5AlsKQbUBRbCXq2tqUVNgWjgWCUoofuU4Uw/2YieJa3Tc
KcIsHeI8YcpnGW5e0ipXEPG/9B9m3T4UVybk8N3LQ7SW8ca6oRZgH7EgKEgmwHD0
SCIMtVDXgQk=
=7ojY
-----END PGP SIGNATURE-----

From barry at python.org  Thu Aug 14 06:50:39 2008
From: barry at python.org (Barry Warsaw)
Date: Thu, 14 Aug 2008 00:50:39 -0400
Subject: [python-committers] PQM?
In-Reply-To: <ca471dc20808132116v6cec6150kdb06d3d19904f7ff@mail.gmail.com>
References: <4838EA2D.7060402@jcea.es> <48A12D81.1040309@v.loewis.de>
	<e69d3ed20808112354t6cb1a55esbc90126b573fb18b@mail.gmail.com>
	<48A13DFA.3080504@v.loewis.de>
	<557787AE-51CD-49EB-B16F-C22F45B9F51E@python.org>
	<48A1DA1A.7090103@v.loewis.de>
	<4F0CDE78-146A-493B-BD7D-7D67291E2799@python.org>
	<1218667291.22748.12.camel@fsol>
	<E0530C6F-0330-43E4-B134-0D24EB5AB0CF@python.org>
	<48A38669.4050204@cheimes.de>
	<ca471dc20808132116v6cec6150kdb06d3d19904f7ff@mail.gmail.com>
Message-ID: <74C813D9-64BD-448F-B6EF-A0387F111F0C@python.org>

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

On Aug 14, 2008, at 12:16 AM, Guido van Rossum wrote:

> I don't have experience with PQM or something like it, but I suspect
> it doesn't scale, and the buildbots are a better approach, because
> they handle multiple platforms.

Just quickly because I've touched on most of these issues in previous  
responses, and I'm pretty damn tired right now. ;)

- - Code reviews: +1 I agree with everything you said here Guido.
- - Buildbots: good for what they do, but because they're reactive (and  
in our case, quite often not working) they don't solve a problem,  
they're an indicator of the problem
- - PQM: right, doesn't scale across multiple platforms, but still  
valuable.  Guards against broken mainline affecting everybody.  E.g.  
would have caught the multiprocessing bug that delayed an earlier  
release affecting at least Linux and OS X.
- - All three can work together to solve different parts of the problem.  
None (IMHO) are enough on their own.  I'm skeptical that reviews +  
buildbots are enough.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSKO5n3EjvBPtnXfVAQL8OgP9FvF8k6NACevHnfwbnOc9YsMe8ScyZ3sG
9HOwLn70G7TXT0Lg3izT+VnLXhAbMUm7a0fNJXStTrWmfMvIiHLqs8W1wdKoJSTN
kyTgpx0p8LkryBfakq09D/nknlylajGfr21vT5zXS5+irgURIq1FW/u7Ry9pzT5l
QtSZ8EyWR2Y=
=c342
-----END PGP SIGNATURE-----

From martin at v.loewis.de  Thu Aug 14 08:22:36 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 14 Aug 2008 08:22:36 +0200
Subject: [python-committers] [Python-Dev] next beta
In-Reply-To: <81550766-7ABA-489D-AEE0-F1350C7F2E55@python.org>
References: <4838EA2D.7060402@jcea.es> <4884581F.8010201@jcea.es>	
	<bbaeab100807211116g4df70dc1o81b1075a88282c93@mail.gmail.com>	
	<1BDCADF2-F6EE-4824-80BF-68CB1760CA7B@python.org>	
	<loom.20080811T095014-204@post.gmane.org>	
	<2F883F29-DAD8-4D4D-948D-DDAD872EB2A4@python.org>	
	<6D041763-67AC-4213-AF2B-4AFBB991C699@python.org>	
	<48A114EB.3090801@v.loewis.de>	
	<e69d3ed20808112308n2ed1739fv3ecb79e2fa1de279@mail.gmail.com>	
	<48A12D81.1040309@v.loewis.de>
	<e69d3ed20808112354t6cb1a55esbc90126b573fb18b@mail.gmail.com>
	<48A13DFA.3080504@v.loewis.de>
	<557787AE-51CD-49EB-B16F-C22F45B9F51E@python.org>
	<48A1DA1A.7090103@v.loewis.de>
	<4F0CDE78-146A-493B-BD7D-7D67291E2799@python.org>
	<48A36F65.1060301@v.loewis.de>
	<81550766-7ABA-489D-AEE0-F1350C7F2E55@python.org>
Message-ID: <48A3CF2C.6080208@v.loewis.de>

> That's true of a certain class of bugs, probably mostly in the C code. 
> I think potential security bugs in Python code will be closer to
> "regular" bug fixes.

While that may be true, I think that are much more infrequent, because
many attack paths (such as memory overwrites leading to remote code
execution) just don't exist. In many cases, it's clear that it is the
application that uses the library in an insecure manner, so many
security fixes involving Python code will be in the applications, not
the library.

In fact, I only recall a single security-related bug fix of Python code,
advisory PSF-2005-001: XML-RPC would allow to invoke arbitrary Python
code. In fixing this, valid uses might have been broken, so the patch
added the allow_dotted_names attribute for such applications. Clearly,
quite some time went into designing a fix for this problem, much more
than for a regular bug fix. This is comparatively ok, since security
fixes for Python library code are so rare.

> I was thinking about preventing commits on the branch.  Most security
> fixes of the type you describe come in through the psrt, and they may
> even be embargoed.  For a closed branch, you'd open it for the security
> patches when the embargo is lifted, make the commits, then close it
> again.  That would at least be a very strong clue that the branch is
> closed :).

That would be fairly easy to do. If there is consensus what branches
are closed, I can come up with a pre-commit hook.

Regards,
Martin

From martin at v.loewis.de  Thu Aug 14 08:54:57 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 14 Aug 2008 08:54:57 +0200
Subject: [python-committers] PQM?
In-Reply-To: <ca471dc20808132116v6cec6150kdb06d3d19904f7ff@mail.gmail.com>
References: <4838EA2D.7060402@jcea.es>
	<48A12D81.1040309@v.loewis.de>	<e69d3ed20808112354t6cb1a55esbc90126b573fb18b@mail.gmail.com>	<48A13DFA.3080504@v.loewis.de>	<557787AE-51CD-49EB-B16F-C22F45B9F51E@python.org>	<48A1DA1A.7090103@v.loewis.de>	<4F0CDE78-146A-493B-BD7D-7D67291E2799@python.org>	<1218667291.22748.12.camel@fsol>	<E0530C6F-0330-43E4-B134-0D24EB5AB0CF@python.org>	<48A38669.4050204@cheimes.de>
	<ca471dc20808132116v6cec6150kdb06d3d19904f7ff@mail.gmail.com>
Message-ID: <48A3D6C1.9010304@v.loewis.de>

> As long as we're touting tools or processes that we have experience
> with, Google uses a combination of tools. One tool is similar to the
> buildbots, running tests *after* stuff has been checked in. A feature
> that buildbot is missing is that it tries to figure which checkin is
> responsible for a particular failure, and mails both the author of
> that change and the owner of the code (if different).

Buildbot does have a blame list. Mailing the developer failed so far
because we didn't have email addresses of each developer. Now, with
the python-committers list, Brett collected them, so such mailing
would be possible.

I'm not sure about mailing the owner of the code: we don't typically
have owners of code, right? Would you consider it useful to support
the case were we do have an owner? Such an ownership database would
need to be maintained, as well, and typically, when we do have owners,
the owner is also the committer.

> Another tool that helps code quality tremendously is mandatory peer
> reviews of all code before checkin. Call me biased because I wrote the
> first version of the tool that most Googlers today use for peer
> reviews (Collin Winter now runs that show) and also open-sourced a
> similar tool (Rietveld, http://codereview.appspot.com) that works with
> Subversion. But I didn't set the policy of mandatory pre-checkin peer
> reviews -- Google had that policy for years before, and other tools
> had already been written.

So would you enforce that policy with tools, too? If so, what would
the workflow look like?

> Anyway, if we're going to change policies around submitting code, I
> would much rather see peer review become a habit than adopt a tool
> like PQM.

The part where I'm skeptical about such a policy is that there might
be a shortage of reviewers. What if a patch on Rietvield doesn't find
a reviewer for a month or so? Many patches in the tracker sit there
for years without any committer reviewing them.

Regards,
Martin


From solipsis at pitrou.net  Thu Aug 14 09:11:25 2008
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Thu, 14 Aug 2008 09:11:25 +0200
Subject: [python-committers] PQM?
In-Reply-To: <5202BC6E-35F4-49E8-989F-8A7D4D7C0AFC@python.org>
References: <4838EA2D.7060402@jcea.es> <4884581F.8010201@jcea.es>
	<bbaeab100807211116g4df70dc1o81b1075a88282c93@mail.gmail.com>
	<1BDCADF2-F6EE-4824-80BF-68CB1760CA7B@python.org>
	<loom.20080811T095014-204@post.gmane.org>
	<2F883F29-DAD8-4D4D-948D-DDAD872EB2A4@python.org>
	<6D041763-67AC-4213-AF2B-4AFBB991C699@python.org>
	<48A114EB.3090801@v.loewis.de>
	<e69d3ed20808112308n2ed1739fv3ecb79e2fa1de279@mail.gmail.com>
	<48A12D81.1040309@v.loewis.de>
	<e69d3ed20808112354t6cb1a55esbc90126b573fb18b@mail.gmail.com>
	<48A13DFA.3080504@v.loewis.de>
	<557787AE-51CD-49EB-B16F-C22F45B9F51E@python.org>
	<48A1DA1A.7090103@v.loewis.de>
	<4F0CDE78-146A-493B-BD7D-7D67291E2799@python.org>
	<1218667291.22748.12.camel@fsol>
	<E0530C6F-0330-43E4-B134-0D24EB5AB0CF@python.org>
	<08Aug13.165230pdt."58698"@synergy1.parc.xerox.com>
	<5202BC6E-35F4-49E8-989F-8A7D4D7C0AFC@python.org>
Message-ID: <1218697885.5619.4.camel@fsol>


[forgot to CC list]

Le jeudi 14 ao?t 2008 ? 00:16 -0400, Barry Warsaw a ?crit :
> It would still solve a problem we have today, which is that the  
> release branch is very often broken when the time comes to cut a  
> release.  We've had to delay several releases because of red buildbots  
> or failing tests across multiple platforms.

But aren't these failures generally intermittent or platform-specific?
The kind which will not necessarily be caught by a PQM (or, worse, will
be attributed to a later change than the really faulty one, making it
impossible for innocent changes to be checked in).



From fredrik at pythonware.com  Thu Aug 14 09:12:32 2008
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Thu, 14 Aug 2008 09:12:32 +0200
Subject: [python-committers] PQM?
In-Reply-To: <48A3D6C1.9010304@v.loewis.de>
References: <4838EA2D.7060402@jcea.es> <48A13DFA.3080504@v.loewis.de>
	<557787AE-51CD-49EB-B16F-C22F45B9F51E@python.org>
	<48A1DA1A.7090103@v.loewis.de>
	<4F0CDE78-146A-493B-BD7D-7D67291E2799@python.org>
	<1218667291.22748.12.camel@fsol>
	<E0530C6F-0330-43E4-B134-0D24EB5AB0CF@python.org>
	<48A38669.4050204@cheimes.de>
	<ca471dc20808132116v6cec6150kdb06d3d19904f7ff@mail.gmail.com>
	<48A3D6C1.9010304@v.loewis.de>
Message-ID: <368a5cd50808140012o48c2cb29ye5f08cbf6de5e00b@mail.gmail.com>

>> Anyway, if we're going to change policies around submitting code, I
>> would much rather see peer review become a habit than adopt a tool
>> like PQM.
>
> The part where I'm skeptical about such a policy is that there might
> be a shortage of reviewers. What if a patch on Rietvield doesn't find
> a reviewer for a month or so? Many patches in the tracker sit there
> for years without any committer reviewing them.

The tracker has zero support for efficient patch review.  Tools like
Rietveld and Review Board are designed for efficient patch and code
review, and not much else.  I don't think you can use the fact that
people find it hard to work with a tool that makes it hard to do
things as an argument against using a tool that makes it easy to do
things...

(has anyone compared Rietveld and Review Board, btw?)

</F>

From solipsis at pitrou.net  Thu Aug 14 09:26:41 2008
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Thu, 14 Aug 2008 09:26:41 +0200
Subject: [python-committers] PQM?
In-Reply-To: <48A3D6C1.9010304@v.loewis.de>
References: <4838EA2D.7060402@jcea.es> <48A12D81.1040309@v.loewis.de>
	<e69d3ed20808112354t6cb1a55esbc90126b573fb18b@mail.gmail.com>
	<48A13DFA.3080504@v.loewis.de>
	<557787AE-51CD-49EB-B16F-C22F45B9F51E@python.org>
	<48A1DA1A.7090103@v.loewis.de>
	<4F0CDE78-146A-493B-BD7D-7D67291E2799@python.org>
	<1218667291.22748.12.camel@fsol>
	<E0530C6F-0330-43E4-B134-0D24EB5AB0CF@python.org>
	<48A38669.4050204@cheimes.de>
	<ca471dc20808132116v6cec6150kdb06d3d19904f7ff@mail.gmail.com>
	<48A3D6C1.9010304@v.loewis.de>
Message-ID: <1218698801.5619.18.camel@fsol>

Le jeudi 14 ao?t 2008 ? 08:54 +0200, "Martin v. L?wis" a ?crit :
> The part where I'm skeptical about such a policy is that there might
> be a shortage of reviewers. What if a patch on Rietvield doesn't find
> a reviewer for a month or so? Many patches in the tracker sit there
> for years without any committer reviewing them.

There's also the problem that some patches can only be understood by one
person, the one who wrote it, and it's somehow still fine because he/she
is the de facto maintainer for that part of code (e.g. ctypes,
bsddb...).

("not finding a reviewer for a month or so" is actually an optimistic
statement; from my short experience with Twisted it can be much longer
than that :-))

That said, I appreciate the advantages of code reviews. But they do take
a lot of time, and can create manpower problems (by lowering throughput
*and* increasing latencies).



From brett at python.org  Thu Aug 14 10:37:36 2008
From: brett at python.org (Brett Cannon)
Date: Thu, 14 Aug 2008 01:37:36 -0700
Subject: [python-committers] PQM?
In-Reply-To: <48A3D6C1.9010304@v.loewis.de>
References: <4838EA2D.7060402@jcea.es> <48A13DFA.3080504@v.loewis.de>
	<557787AE-51CD-49EB-B16F-C22F45B9F51E@python.org>
	<48A1DA1A.7090103@v.loewis.de>
	<4F0CDE78-146A-493B-BD7D-7D67291E2799@python.org>
	<1218667291.22748.12.camel@fsol>
	<E0530C6F-0330-43E4-B134-0D24EB5AB0CF@python.org>
	<48A38669.4050204@cheimes.de>
	<ca471dc20808132116v6cec6150kdb06d3d19904f7ff@mail.gmail.com>
	<48A3D6C1.9010304@v.loewis.de>
Message-ID: <bbaeab100808140137r78909bcer3f97e5edec524b64@mail.gmail.com>

On Wed, Aug 13, 2008 at 11:54 PM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
[SNIP]
>> Anyway, if we're going to change policies around submitting code, I
>> would much rather see peer review become a habit than adopt a tool
>> like PQM.
>
> The part where I'm skeptical about such a policy is that there might
> be a shortage of reviewers. What if a patch on Rietvield doesn't find
> a reviewer for a month or so? Many patches in the tracker sit there
> for years without any committer reviewing them.
>

It would be a change in culture for us, that's for sure. The question
becomes whether the drop in patch throughput is justified by an
increase of patch quality and stability in the code?

-Brett

From solipsis at pitrou.net  Thu Aug 14 11:27:56 2008
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Thu, 14 Aug 2008 11:27:56 +0200 (CEST)
Subject: [python-committers] PQM?
In-Reply-To: <bbaeab100808140137r78909bcer3f97e5edec524b64@mail.gmail.com>
References: <4838EA2D.7060402@jcea.es> <48A13DFA.3080504@v.loewis.de>
	<557787AE-51CD-49EB-B16F-C22F45B9F51E@python.org>
	<48A1DA1A.7090103@v.loewis.de>
	<4F0CDE78-146A-493B-BD7D-7D67291E2799@python.org>
	<1218667291.22748.12.camel@fsol>
	<E0530C6F-0330-43E4-B134-0D24EB5AB0CF@python.org>
	<48A38669.4050204@cheimes.de>
	<ca471dc20808132116v6cec6150kdb06d3d19904f7ff@mail.gmail.com>
	<48A3D6C1.9010304@v.loewis.de>
	<bbaeab100808140137r78909bcer3f97e5edec524b64@mail.gmail.com>
Message-ID: <16ca510df2fb6631feeb4af7678f0550.squirrel@webmail.nerim.net>


> It would be a change in culture for us, that's for sure. The question
> becomes whether the drop in patch throughput is justified by an
> increase of patch quality and stability in the code?

Well, let's take the multiprocessing example. The question is:
- would an a priori review have been able to uncover the most subtle bugs?
- would someone have done that review at all, and how long would it have
taken before it had been done?
- if we had delayed the inclusion of multiprocessing in the mainline,
doesn't it mean it would have got almost no testing since people are
unlikely to test specific branches rather than the "official trunk"?
- isn't the inclusion of multiprocessing itself, even if subtle bugs
remain, an increase of quality since it gives people a standard and rather
good package for doing parallel stuff, rather than baking their own
defective ad-hoc solutions?

The thing I want to point out in the latter item is that measuring quality
solely by the number of bugs or the stability of a bunch of buildbots is
wrong (although of course fixing bugs and having green buildbots *is*
important). Sometimes committing an imperfect patch can be better than
committing nothing at all.

Regards

Antoine.



From mal at egenix.com  Thu Aug 14 12:25:22 2008
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu, 14 Aug 2008 12:25:22 +0200
Subject: [python-committers] PQM?
In-Reply-To: <bbaeab100808140137r78909bcer3f97e5edec524b64@mail.gmail.com>
References: <4838EA2D.7060402@jcea.es>
	<48A13DFA.3080504@v.loewis.de>	<557787AE-51CD-49EB-B16F-C22F45B9F51E@python.org>	<48A1DA1A.7090103@v.loewis.de>	<4F0CDE78-146A-493B-BD7D-7D67291E2799@python.org>	<1218667291.22748.12.camel@fsol>	<E0530C6F-0330-43E4-B134-0D24EB5AB0CF@python.org>	<48A38669.4050204@cheimes.de>	<ca471dc20808132116v6cec6150kdb06d3d19904f7ff@mail.gmail.com>	<48A3D6C1.9010304@v.loewis.de>
	<bbaeab100808140137r78909bcer3f97e5edec524b64@mail.gmail.com>
Message-ID: <48A40812.5000906@egenix.com>

On 2008-08-14 10:37, Brett Cannon wrote:
> On Wed, Aug 13, 2008 at 11:54 PM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> [SNIP]
>>> Anyway, if we're going to change policies around submitting code, I
>>> would much rather see peer review become a habit than adopt a tool
>>> like PQM.
>> The part where I'm skeptical about such a policy is that there might
>> be a shortage of reviewers. What if a patch on Rietvield doesn't find
>> a reviewer for a month or so? Many patches in the tracker sit there
>> for years without any committer reviewing them.
>>
> 
> It would be a change in culture for us, that's for sure. The question
> becomes whether the drop in patch throughput is justified by an
> increase of patch quality and stability in the code?

I don't know about other developers, but I tend to do code review
by looking at the patch listings on the checkins list. While that
doesn't allow finding problems before the checkin, it does allow
finding them shortly afterwards and fairly quickly.

Of course, it's not as rigorous as using a special tool, but it
also doesn't get in the way when the patches are in fact in good
shape (which most of them are).

For everyday patches, I don't think we need a tool to help us
with code review.

For larger chunks or new code that has to be
reviewed on the tracker first, a peer review tool would make
things easier, actually just a way to open a patch in the browser
without having to first download it would already simplify things
a lot ;-) (this currently doesn't always work due to MIME issues
with the various different patch upload formats, e.g. .patch files,
.txt files, etc.)

Discussing such larger chunks on the tracker before they go in
is enough peer review and delay, IMHO.

In the end, some bugs will always get past all these barriers,
regardless on how difficult you make it.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Aug 14 2008)
 >>> 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 mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX 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

From facundobatista at gmail.com  Thu Aug 14 13:25:51 2008
From: facundobatista at gmail.com (Facundo Batista)
Date: Thu, 14 Aug 2008 08:25:51 -0300
Subject: [python-committers] PQM?
In-Reply-To: <2F9A07FC-8DCC-46B9-A89D-412ABBF7BAE3@python.org>
References: <4838EA2D.7060402@jcea.es>
	<e69d3ed20808112354t6cb1a55esbc90126b573fb18b@mail.gmail.com>
	<48A13DFA.3080504@v.loewis.de>
	<557787AE-51CD-49EB-B16F-C22F45B9F51E@python.org>
	<48A1DA1A.7090103@v.loewis.de>
	<4F0CDE78-146A-493B-BD7D-7D67291E2799@python.org>
	<1218667291.22748.12.camel@fsol>
	<E0530C6F-0330-43E4-B134-0D24EB5AB0CF@python.org>
	<bbaeab100808131949r4693814eibf12a0dcd9bb78ad@mail.gmail.com>
	<2F9A07FC-8DCC-46B9-A89D-412ABBF7BAE3@python.org>
Message-ID: <e04bdf310808140425q75f1f1c3se7ad0c0170f1da5c@mail.gmail.com>

2008/8/14 Barry Warsaw <barry at python.org>:

> it would be the developer who committed the broken change.  The problem of
> not having access to all the platforms, or not being able to debug problems
> on those platforms is a different issue.

I want to grab a little attention on this issue. It happened to me a
few times that I commited code that caused platform specific problems
(working with sockets, for example): sometimes it's all ok, but it
fails in *one* of the buildbots.

Fixing those issues is a PIA, because sometimes you may have some clue
of what could have gone wrong, but it's complicated, because you can
not try it.

Don't know really how to improve this situations. There're two things
that it'd be great to have, though:

- Not only the traceback, but a very detailed traceback to download.
With "very detailed traceback" I mean a traceback like the cgitb one:
with the state of all the objects in all the frames in the traceback.

- A VirtualBox image with the buildbot system ready to "svn up, make
and test". It needs to be done only once by somebody who knows that
platform. Note that we may face license issues here.

OTOH, I think I read somewhere that you somehow can send a patch only
to that buildbot... where I can read more about this?

Thank you!!

-- 
. Facundo

Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/

From barry at python.org  Thu Aug 14 14:30:04 2008
From: barry at python.org (Barry Warsaw)
Date: Thu, 14 Aug 2008 08:30:04 -0400
Subject: [python-committers] PQM?
In-Reply-To: <48A3D6C1.9010304@v.loewis.de>
References: <4838EA2D.7060402@jcea.es>
	<48A12D81.1040309@v.loewis.de>	<e69d3ed20808112354t6cb1a55esbc90126b573fb18b@mail.gmail.com>	<48A13DFA.3080504@v.loewis.de>	<557787AE-51CD-49EB-B16F-C22F45B9F51E@python.org>	<48A1DA1A.7090103@v.loewis.de>	<4F0CDE78-146A-493B-BD7D-7D67291E2799@python.org>	<1218667291.22748.12.camel@fsol>	<E0530C6F-0330-43E4-B134-0D24EB5AB0CF@python.org>	<48A38669.4050204@cheimes.de>
	<ca471dc20808132116v6cec6150kdb06d3d19904f7ff@mail.gmail.com>
	<48A3D6C1.9010304@v.loewis.de>
Message-ID: <ED228A5B-BFF8-49B2-8783-A42171145758@python.org>

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

On Aug 14, 2008, at 2:54 AM, Martin v. L?wis wrote:

>> As long as we're touting tools or processes that we have experience
>> with, Google uses a combination of tools. One tool is similar to the
>> buildbots, running tests *after* stuff has been checked in. A feature
>> that buildbot is missing is that it tries to figure which checkin is
>> responsible for a particular failure, and mails both the author of
>> that change and the owner of the code (if different).
>
> Buildbot does have a blame list. Mailing the developer failed so far
> because we didn't have email addresses of each developer. Now, with
> the python-committers list, Brett collected them, so such mailing
> would be possible.
>
> I'm not sure about mailing the owner of the code: we don't typically
> have owners of code, right? Would you consider it useful to support
> the case were we do have an owner? Such an ownership database would
> need to be maintained, as well, and typically, when we do have owners,
> the owner is also the committer.

I'm not in favor of code owners, but commit owners might be  
worthwhile.  If we have the email addresses now, and can easily enable  
it, then I think we should have the buildbots email both this mailing  
list and the owner of the commit when things break.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSKQlTXEjvBPtnXfVAQIxIgQAjg0mky3TA7Eq/ey7Jk3lXwD1V2eRJNHa
aL4wfmumubEsVq3PzsubIguN7+uLEJZrj7DhOD00sb18BL0s+sxBlV48sLSBI0xL
7HHJWF9U8sTOZEB8UpdYqtNGuqLdMhaBNWl7G9XqC+jy37ycwYD9LWnezmVABTH3
rxwg39uRkY8=
=toLj
-----END PGP SIGNATURE-----

From barry at python.org  Thu Aug 14 14:39:07 2008
From: barry at python.org (Barry Warsaw)
Date: Thu, 14 Aug 2008 08:39:07 -0400
Subject: [python-committers] PQM?
In-Reply-To: <16ca510df2fb6631feeb4af7678f0550.squirrel@webmail.nerim.net>
References: <4838EA2D.7060402@jcea.es> <48A13DFA.3080504@v.loewis.de>
	<557787AE-51CD-49EB-B16F-C22F45B9F51E@python.org>
	<48A1DA1A.7090103@v.loewis.de>
	<4F0CDE78-146A-493B-BD7D-7D67291E2799@python.org>
	<1218667291.22748.12.camel@fsol>
	<E0530C6F-0330-43E4-B134-0D24EB5AB0CF@python.org>
	<48A38669.4050204@cheimes.de>
	<ca471dc20808132116v6cec6150kdb06d3d19904f7ff@mail.gmail.com>
	<48A3D6C1.9010304@v.loewis.de>
	<bbaeab100808140137r78909bcer3f97e5edec524b64@mail.gmail.com>
	<16ca510df2fb6631feeb4af7678f0550.squirrel@webmail.nerim.net>
Message-ID: <E15359ED-2966-44A5-8B79-43394AE052EE@python.org>

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

On Aug 14, 2008, at 5:27 AM, Antoine Pitrou wrote:

>
>> It would be a change in culture for us, that's for sure. The question
>> becomes whether the drop in patch throughput is justified by an
>> increase of patch quality and stability in the code?
>
> Well, let's take the multiprocessing example. The question is:
> - would an a priori review have been able to uncover the most subtle  
> bugs?
> - would someone have done that review at all, and how long would it  
> have
> taken before it had been done?
> - if we had delayed the inclusion of multiprocessing in the mainline,
> doesn't it mean it would have got almost no testing since people are
> unlikely to test specific branches rather than the "official trunk"?
> - isn't the inclusion of multiprocessing itself, even if subtle bugs
> remain, an increase of quality since it gives people a standard and  
> rather
> good package for doing parallel stuff, rather than baking their own
> defective ad-hoc solutions?
>
> The thing I want to point out in the latter item is that measuring  
> quality
> solely by the number of bugs or the stability of a bunch of  
> buildbots is
> wrong (although of course fixing bugs and having green buildbots *is*
> important). Sometimes committing an imperfect patch can be better than
> committing nothing at all.

I think this is a case where PQM might have helped.  Assuming the  
build/test would uncover these subtle bugs, the multiprocessing code  
would not have landed.  You would then probably publish a branch with  
those (failing) changes and rally the help you needed to fix those  
problems.  Then you'd try to land it again.

The workflow would have likely been very similar to what happened for  
this code, except that it would be happening on a branch, not on the  
mainline.  Maybe no one would have been motivated enough to get them  
working if they weren't breaking mainline.  The tradeoff is  
instability in the mainline and uncertainty as to whether the mainline  
is of high enough quality to release.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSKQna3EjvBPtnXfVAQKFgAP9HS2HRbhD5X1SOyRqi6aopmNOYyO216g0
2AL4xintyCvqPJaU8FNkBT4XEM9ayCt39pvpeBFDUWN1t6r2xZ7UR22ye0Ic2aei
otC5dmZFMEtDOjhbqmFQ6YmYs9ZvpvrQ37h01ath4uX2lVjjH/h91m4w6fJ7FYQT
kIT456eW9nU=
=hzTW
-----END PGP SIGNATURE-----

From lists at cheimes.de  Thu Aug 14 15:51:59 2008
From: lists at cheimes.de (Christian Heimes)
Date: Thu, 14 Aug 2008 15:51:59 +0200
Subject: [python-committers] PQM?
In-Reply-To: <E15359ED-2966-44A5-8B79-43394AE052EE@python.org>
References: <4838EA2D.7060402@jcea.es>
	<48A13DFA.3080504@v.loewis.de>	<557787AE-51CD-49EB-B16F-C22F45B9F51E@python.org>	<48A1DA1A.7090103@v.loewis.de>	<4F0CDE78-146A-493B-BD7D-7D67291E2799@python.org>	<1218667291.22748.12.camel@fsol>	<E0530C6F-0330-43E4-B134-0D24EB5AB0CF@python.org>	<48A38669.4050204@cheimes.de>	<ca471dc20808132116v6cec6150kdb06d3d19904f7ff@mail.gmail.com>	<48A3D6C1.9010304@v.loewis.de>	<bbaeab100808140137r78909bcer3f97e5edec524b64@mail.gmail.com>	<16ca510df2fb6631feeb4af7678f0550.squirrel@webmail.nerim.net>
	<E15359ED-2966-44A5-8B79-43394AE052EE@python.org>
Message-ID: <48A4387F.2020201@cheimes.de>

Barry Warsaw wrote:
> I think this is a case where PQM might have helped.  Assuming the 
> build/test would uncover these subtle bugs, the multiprocessing code 
> would not have landed.  You would then probably publish a branch with d t
> those (failing) changes and rally the help you needed to fix those 
> problems.  Then you'd try to land it again.
> 
> The workflow would have likely been very similar to what happened for 
> this code, except that it would be happening on a branch, not on the 
> mainline.  Maybe no one would have been motivated enough to get them 
> working if they weren't breaking mainline.  The tradeoff is instability 
> in the mainline and uncertainty as to whether the mainline is of high 
> enough quality to release.

I suggest that we should use branches to a greater extend. New features 
or updates of existing code should happen on a branch. A branch must not 
be merged until it's tested on all major platforms (Linux i386, Linux 
AMD64, Mac OS X and Win32) and peer reviewed by another developer.

During my time as a Zope and Plone developer and at various XP sprints 
I've utilized the branch development and peer reviewing workflow with 
great success. I assume the majority of Python developers don't do 
branches because it's an expensive and annoying operation with svn. Well 
branching isn't so annoying but merging and keeping a branch up to date 
definitely is. Once we have a VCS with cheap branching and easy merging 
we should switch to branched development.

Christian

From barry at python.org  Thu Aug 14 15:53:58 2008
From: barry at python.org (Barry Warsaw)
Date: Thu, 14 Aug 2008 09:53:58 -0400
Subject: [python-committers] PQM?
In-Reply-To: <48A4387F.2020201@cheimes.de>
References: <4838EA2D.7060402@jcea.es>
	<48A13DFA.3080504@v.loewis.de>	<557787AE-51CD-49EB-B16F-C22F45B9F51E@python.org>	<48A1DA1A.7090103@v.loewis.de>	<4F0CDE78-146A-493B-BD7D-7D67291E2799@python.org>	<1218667291.22748.12.camel@fsol>	<E0530C6F-0330-43E4-B134-0D24EB5AB0CF@python.org>	<48A38669.4050204@cheimes.de>	<ca471dc20808132116v6cec6150kdb06d3d19904f7ff@mail.gmail.com>	<48A3D6C1.9010304@v.loewis.de>	<bbaeab100808140137r78909bcer3f97e5edec524b64@mail.gmail.com>	<16ca510df2fb6631feeb4af7678f0550.squirrel@webmail.nerim.net>
	<E15359ED-2966-44A5-8B79-43394AE052EE@python.org>
	<48A4387F.2020201@cheimes.de>
Message-ID: <2A4255B2-FEF1-4C94-88EF-04FA75B2C375@python.org>

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

On Aug 14, 2008, at 9:51 AM, Christian Heimes wrote:

> During my time as a Zope and Plone developer and at various XP  
> sprints I've utilized the branch development and peer reviewing  
> workflow with great success. I assume the majority of Python  
> developers don't do branches because it's an expensive and annoying  
> operation with svn. Well branching isn't so annoying but merging and  
> keeping a branch up to date definitely is. Once we have a VCS with  
> cheap branching and easy merging we should switch to branched  
> development.

+1 to that, but you knew I was going to say that :)

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSKQ49nEjvBPtnXfVAQIkUQP/Qm55TtW8W+qGWxtAaEAEBRHr0EM7330M
xoy/M62KOsIcec1s/J/msDtzJJaVGFMJVFiuQqL/gML/vWh3pIeg85AoaMbu4Me7
7IzaaBckaEVSTk11RIyqizW4Q9rikFMVJvPSJOpk/v3d2NpcMdYr1Dlks4besnUW
ZbRHZdy8XO8=
=HlNP
-----END PGP SIGNATURE-----

From lists at cheimes.de  Thu Aug 14 16:05:49 2008
From: lists at cheimes.de (Christian Heimes)
Date: Thu, 14 Aug 2008 16:05:49 +0200
Subject: [python-committers] PQM?
In-Reply-To: <ca471dc20808132116v6cec6150kdb06d3d19904f7ff@mail.gmail.com>
References: <4838EA2D.7060402@jcea.es> <48A12D81.1040309@v.loewis.de>	
	<e69d3ed20808112354t6cb1a55esbc90126b573fb18b@mail.gmail.com>	
	<48A13DFA.3080504@v.loewis.de>	
	<557787AE-51CD-49EB-B16F-C22F45B9F51E@python.org>	
	<48A1DA1A.7090103@v.loewis.de>	
	<4F0CDE78-146A-493B-BD7D-7D67291E2799@python.org>	
	<1218667291.22748.12.camel@fsol>	
	<E0530C6F-0330-43E4-B134-0D24EB5AB0CF@python.org>	
	<48A38669.4050204@cheimes.de>
	<ca471dc20808132116v6cec6150kdb06d3d19904f7ff@mail.gmail.com>
Message-ID: <48A43BBD.5010800@cheimes.de>

Guido van Rossum wrote:
> [Hey Christian, welcome back! (It seems we hadn't heard much from you
> for a while...)]

Yeah, I had an acute case of burnout syndrome. I tried to do far too 
many things in parallel. I prescribed myself to focus on the most 
important tasks like my new apartment and my job first. Heck, some of my 
stuff is still in boxes! Relocating is sooo time consuming.

> As long as we're touting tools or processes that we have experience
> with, Google uses a combination of tools. One tool is similar to the
> buildbots, running tests *after* stuff has been checked in. A feature
> that buildbot is missing is that it tries to figure which checkin is
> responsible for a particular failure, and mails both the author of
> that change and the owner of the code (if different).

Our buildbot system has another issue. It's sending out far too many 
mails with too many text. The s/n ratio is bad which makes it tedious to 
study the reports. I'd prefer a summary once a day which lists the 
failing build bots, platforms and tests. Add some links to extensive 
test output, revisions and authors and you'd get a short report instead 
of ten extensive reports.

> Anyway, if we're going to change policies around submitting code, I
> would much rather see peer review become a habit than adopt a tool
> like PQM.

I agree!

Christian

From theller at ctypes.org  Thu Aug 14 16:27:05 2008
From: theller at ctypes.org (Thomas Heller)
Date: Thu, 14 Aug 2008 16:27:05 +0200
Subject: [python-committers] PQM?
In-Reply-To: <48A4387F.2020201@cheimes.de>
References: <4838EA2D.7060402@jcea.es>	<48A13DFA.3080504@v.loewis.de>	<557787AE-51CD-49EB-B16F-C22F45B9F51E@python.org>	<48A1DA1A.7090103@v.loewis.de>	<4F0CDE78-146A-493B-BD7D-7D67291E2799@python.org>	<1218667291.22748.12.camel@fsol>	<E0530C6F-0330-43E4-B134-0D24EB5AB0CF@python.org>	<48A38669.4050204@cheimes.de>	<ca471dc20808132116v6cec6150kdb06d3d19904f7ff@mail.gmail.com>	<48A3D6C1.9010304@v.loewis.de>	<bbaeab100808140137r78909bcer3f97e5edec524b64@mail.gmail.com>	<16ca510df2fb6631feeb4af7678f0550.squirrel@webmail.nerim.net>	<E15359ED-2966-44A5-8B79-43394AE052EE@python.org>
	<48A4387F.2020201@cheimes.de>
Message-ID: <48A440B9.5000006@ctypes.org>

Christian Heimes schrieb:
> 
> I suggest that we should use branches to a greater extend. New 
> features or updates of existing code should happen on a branch.

+1

> A branch must not be merged until it's tested on all major platforms 
> (Linux i386, Linux AMD64, Mac OS X and Win32) and peer reviewed by 
> another developer.

+1 for the major platforms, -0 for the peer review.

> During my time as a Zope and Plone developer and at various XP 
> sprints I've utilized the branch development and peer reviewing 
> workflow with great success. I assume the majority of Python 
> developers don't do branches because it's an expensive and annoying 
> operation with svn.

Actually I don't find branching expensive - why so you think so?
Annoying - hm, no, I'm not sure.
The only additional work that should be done is to merge the branch
when (if!) it's ready, delete the branch when it is not needed any more,
and remove the local branch checkout(s).

> Well branching isn't so annoying but merging and keeping a branch up
> to date definitely is. Once we have a VCS with cheap branching and
> easy merging we should switch to branched development.

Well, svnmerge makes keeping a branch up to date pretty painless imo.

I did the pep3118 implementation for ctypes in a separate branch, I did
upgrade the years-old libffi in a separate branch, maybe even more.

This worked well for me, and the big advantage was that I coud trigger
builds for these branches on the buildbots on platforms where I have
no other access to.

-- 
Thanks,
Thomas

From lists at cheimes.de  Thu Aug 14 16:33:50 2008
From: lists at cheimes.de (Christian Heimes)
Date: Thu, 14 Aug 2008 16:33:50 +0200
Subject: [python-committers] PQM?
In-Reply-To: <8D25F11C-2E17-44F9-932E-E8E2831EAF47@python.org>
References: <4838EA2D.7060402@jcea.es>
	<4884581F.8010201@jcea.es>	<bbaeab100807211116g4df70dc1o81b1075a88282c93@mail.gmail.com>	<1BDCADF2-F6EE-4824-80BF-68CB1760CA7B@python.org>	<loom.20080811T095014-204@post.gmane.org>	<2F883F29-DAD8-4D4D-948D-DDAD872EB2A4@python.org>	<6D041763-67AC-4213-AF2B-4AFBB991C699@python.org>	<48A114EB.3090801@v.loewis.de>	<e69d3ed20808112308n2ed1739fv3ecb79e2fa1de279@mail.gmail.com>	<48A12D81.1040309@v.loewis.de>	<e69d3ed20808112354t6cb1a55esbc90126b573fb18b@mail.gmail.com>	<48A13DFA.3080504@v.loewis.de>	<557787AE-51CD-49EB-B16F-C22F45B9F51E@python.org>	<48A1DA1A.7090103@v.loewis.de>	<4F0CDE78-146A-493B-BD7D-7D67291E2799@python.org>	<1218667291.22748.12.camel@fsol>
	<E0530C6F-0330-43E4-B134-0D24EB5AB0CF@python.org>
	<48A38669.4050204@cheimes.de>
	<8D25F11C-2E17-44F9-932E-E8E2831EAF47@python.org>
Message-ID: <48A4424E.3000600@cheimes.de>

Barry Warsaw wrote:
> Unfortunately, they're not being solved without PQM either!  Really, 
> we've had to delay releases several times because the branches were 
> broken across multiple operating systems.  Pleading on the mailing lists 
> doesn't help.  Hanging out on irc doesn't help.  Having Benjamin, Georg, 
> and others kicking ass on #python-dev the day of a release, is great, 
> but it's also asking a lot of them.

Yeah, I concur with you. I've also done my fair share of nights 
dragging, kicking and punching the code into shape for a release. It 
sucks and it's sending my coffee bill sky high.

By the way the guys are totally awesome, dude. :)

> That's what branches are for.  I really strongly feel that the mainlines 
> (by which I mean the branches we cut releases from) should always be in 
> a releasable state.  We should never be committing broken tests to these 
> mainlines.  If you spot a problem you can't fix, create a branch and 
> commit the broken test there, and ask for help with that branch.  The 
> mainline isn't (IMHO) the place for that.
> 
> You're right that it will slow us down, but only on the mainline.  
> That's a good thing, especially if it buys you high quality.

Sticking to our own rules would also buy us quality ... Let's not add 
new features to our code base during the beta phase, please. Although 
the addition of multiprocessing had some merit, we shouldn't to the same 
mistake twice.

Perhaps we could adopt a release plan similar to Ubuntu. They have 
releases with cool, new and bleeding edge stuff followed by a release 
that focuses on stability and long term support. Python 2.6 and 
especially 3.0 are releases with new features. What do you think about 
focusing on stability and long time support for 2.7 and 3.1? 2.7 might 
be the last version of the 2.x series and we sure gonna have to fix lots 
of issues in the 3.x series until it's matured.

Christian

From janssen at parc.com  Thu Aug 14 17:54:17 2008
From: janssen at parc.com (Bill Janssen)
Date: Thu, 14 Aug 2008 08:54:17 PDT
Subject: [python-committers] PQM?
In-Reply-To: <5202BC6E-35F4-49E8-989F-8A7D4D7C0AFC@python.org> 
References: <4838EA2D.7060402@jcea.es> <4884581F.8010201@jcea.es>
	<bbaeab100807211116g4df70dc1o81b1075a88282c93@mail.gmail.com>
	<1BDCADF2-F6EE-4824-80BF-68CB1760CA7B@python.org>
	<loom.20080811T095014-204@post.gmane.org>
	<2F883F29-DAD8-4D4D-948D-DDAD872EB2A4@python.org>
	<6D041763-67AC-4213-AF2B-4AFBB991C699@python.org>
	<48A114EB.3090801@v.loewis.de>
	<e69d3ed20808112308n2ed1739fv3ecb79e2fa1de279@mail.gmail.com>
	<48A12D81.1040309@v.loewis.de>
	<e69d3ed20808112354t6cb1a55esbc90126b573fb18b@mail.gmail.com>
	<48A13DFA.3080504@v.loewis.de>
	<557787AE-51CD-49EB-B16F-C22F45B9F51E@python.org>
	<48A1DA1A.7090103@v.loewis.de>
	<4F0CDE78-146A-493B-BD7D-7D67291E2799@python.org>
	<1218667291.22748.12.camel@fsol>
	<E0530C6F-0330-43E4-B134-0D24EB5AB0CF@python.org>
	<08Aug13.165230pdt."58698"@synergy1.parc.xerox.com>
	<5202BC6E-35F4-49E8-989F-8A7D4D7C0AFC@python.org>
Message-ID: <08Aug14.085422pdt."58698"@synergy1.parc.xerox.com>

> > What platform would it run the test suite on?  Presumably the same one
> > I tested on before I submitted the patch :-).
> 
> I think we'd just have to pick one.  It would probably be a *nix based  
> system.

So everyone who wanted to work on the system would effectively have to
go out and get one of those.  To my mind, that's a non-starter.

Bill

From gustavo at niemeyer.net  Thu Aug 14 18:36:48 2008
From: gustavo at niemeyer.net (Gustavo Niemeyer)
Date: Thu, 14 Aug 2008 13:36:48 -0300
Subject: [python-committers] PQM?
In-Reply-To: <74C813D9-64BD-448F-B6EF-A0387F111F0C@python.org>
References: <4838EA2D.7060402@jcea.es> <48A13DFA.3080504@v.loewis.de>
	<557787AE-51CD-49EB-B16F-C22F45B9F51E@python.org>
	<48A1DA1A.7090103@v.loewis.de>
	<4F0CDE78-146A-493B-BD7D-7D67291E2799@python.org>
	<1218667291.22748.12.camel@fsol>
	<E0530C6F-0330-43E4-B134-0D24EB5AB0CF@python.org>
	<48A38669.4050204@cheimes.de>
	<ca471dc20808132116v6cec6150kdb06d3d19904f7ff@mail.gmail.com>
	<74C813D9-64BD-448F-B6EF-A0387F111F0C@python.org>
Message-ID: <643d90130808140936h408567cevf61168f8567eaa7@mail.gmail.com>

Hey Barry,

First, let me thank you for taking the energy to express many interesting
points in that discussion.

>> I don't have experience with PQM or something like it, but I suspect
>> it doesn't scale, and the buildbots are a better approach, because
>> they handle multiple platforms.
(...)
> - - PQM: right, doesn't scale across multiple platforms, but still valuable.
>  Guards against broken mainline affecting everybody.  E.g. would have caught
> the multiprocessing bug that delayed an earlier release affecting at least
> Linux and OS X.

I'm not sure I get what's the scaling issue here.  It's likely that
you guys have
some experience that I lack, and thus are talking about an obvious issue
that I'm not aware of.

We're actually adopting a PQM-based approach *precisely* because we have
to maintain a code base in multiple versions of the same platform, and thus
can't be sure that the tests will continue working just by running the suite in
our own environments.   In this case PQM will help precisely because running
tests locally "doesn't scale", which is why I'm a bit surprised by the
straightforward agreement on the point above.

What exactly is the "doesnt' scale" issue in this case?

-- 
Gustavo Niemeyer
http://niemeyer.net

From martin at v.loewis.de  Thu Aug 14 19:14:50 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 14 Aug 2008 19:14:50 +0200
Subject: [python-committers] PQM?
In-Reply-To: <643d90130808140936h408567cevf61168f8567eaa7@mail.gmail.com>
References: <4838EA2D.7060402@jcea.es>
	<48A13DFA.3080504@v.loewis.de>	<557787AE-51CD-49EB-B16F-C22F45B9F51E@python.org>	<48A1DA1A.7090103@v.loewis.de>	<4F0CDE78-146A-493B-BD7D-7D67291E2799@python.org>	<1218667291.22748.12.camel@fsol>	<E0530C6F-0330-43E4-B134-0D24EB5AB0CF@python.org>	<48A38669.4050204@cheimes.de>	<ca471dc20808132116v6cec6150kdb06d3d19904f7ff@mail.gmail.com>	<74C813D9-64BD-448F-B6EF-A0387F111F0C@python.org>
	<643d90130808140936h408567cevf61168f8567eaa7@mail.gmail.com>
Message-ID: <48A4680A.7080202@v.loewis.de>

> What exactly is the "doesnt' scale" issue in this case?

I don't actually know PQM, but from what I hear, it appears that
PQM can't run tests for a single patch on all of Solaris, Linux,
Windows, and OS X before accepting it. Instead, PQM will run the
tests on the same machine it runs on itself, and only on that
machine.

Regards,
Martin


From brett at python.org  Thu Aug 14 20:06:03 2008
From: brett at python.org (Brett Cannon)
Date: Thu, 14 Aug 2008 11:06:03 -0700
Subject: [python-committers] improving our code quality [my summary of the
	"PQM" thread]
Message-ID: <bbaeab100808141106n5ee44e57k93936aa8def7ff06@mail.gmail.com>

The thread on PQM has now grown multiple points and it becoming a
little hard to follow since it is pulling in a bunch of ideas not
directly related to a PQM system, so I am going to attempt to
summarize the points brought up here. SUMMARY: it's great we are
talking about this, but I think this would be better to discuss after
2.6/3.0 is out the door.

What are our dev rules, and are we following them?
---------------------------------------------------------------------

Obviously this is all pointing out the fact that Python's popularity
has grown such that the amount of hours available from core developers
is far exceeded by what we really need to keep stuff going the way we
have been doing things. Short of tossing out commit privileges like
candy on Halloween outside of a grade school, something really should
change.

We already have some things in place that do help. Requiring tests has
helped catch issues on the buildbots and made sure we didn't repeat
the same mistakes. We also all know better than to introduce anything
major during the beta cycle, but the thought of having some solution
for multi-core processing was too tempting so we ignored general
practice for the multiprocessing module and now we are paying for it
late in the release cycle. We also want everyone to run the ENTIRE
testing suite before a commit is made, but I am sure we are all guilty
of skipping a full '-u all' run when the change is thought to be minor
(and I know I never run with random test order like the buildbots).


Code reviews
-------------------

One suggestion on how to improve the situation has been code reviews.
Ideas have ranged from code reviews for everything to "who needs code
reviews?" Doing a code review on everything will obviously lower the
bandwidth on committed code and we already don't have that many people
who review pre-existing patches as it is. But some review should
probably be done for anything significant. I am leery of suggesting we
go with guidelines based on line count, but probably anything that
takes more than an afternoon to implement should probably get a code
review. And yes, working in branches would help with this.


Buildbots
-------------

We also have the buildbots which are handy when you are trying to fix
something that is multi-platform, but otherwise they are just email
generators. I think we really need to work on fix the various flaky
tests so that false-positive failures stop occurring and leading to
people ignoring the buildbot emails. And I personally like Christian's
idea of a single summary email at the end of the day of buildbots that
are still failing that goes to everyone potentially involved in the
breakage along with to a mailing list.


PQM
-------

There is also the PQM suggestion to make sure we always at least have
some general sanity in the code base. But a PQM system would probably
only work once the test suite is not flaky anymore as having some typo
in a comment be rejected because test_kqueue failed again is not going
to go over well with most people. And that also goes for OS-specific
failures on a platform I am not running on. Honestly the PQM system
probably wouldn't be necessary if people just ran the entire test
suite before a checkin. And if people never checked in if there was
any failure (related to their code or not) we would probably get the
test suite cleaned up a lot faster as well.


How are we going to solve this?
------------------------------------------

I think a thorough discussion on how we have been handling development
is needed. We all want to continue to enjoy developing for Python and
we want it to continue to be a high-quality project. Because of this
we might have to compromise on what we might do if this were a
business with paid positions, but I don't think it will be anything
major. And I think the 2.6/3.0 development cycle has shown we really
should be changing something to make our lives easier.

But I honestly think this discussion should wait until after we go
final with 2.6/3.0. Once that happens and we are all not running
around trying to get a release out, then we should start from the
ground up and re-evaluate what we need to change. That includes the
workflow in the issue tracker, how the buildbots are used, what our
expected best practices are, cleaning up the test suite, how serious
we are about moving to a distributed VCS, whether we want a PQM, do we
want code reviews, etc. But I really think we should be putting the
time in now to b3 and working towards hitting final before we delve
into this lengthy conversation.

And yes, I am willing to help help with all of this through PEPs,
documenting what are guidelines are for new developers, doing stuff
through the infrastructure committee, etc. (although importlib will be
finished first, although not necessarily committed if our commit
practices change, since I had to miss 3.0 in order to get PEP 3108
done and I refuse to miss another release).

-Brett

From barry at python.org  Thu Aug 14 20:21:09 2008
From: barry at python.org (Barry Warsaw)
Date: Thu, 14 Aug 2008 14:21:09 -0400
Subject: [python-committers] improving our code quality [my summary of
	the "PQM" thread]
In-Reply-To: <bbaeab100808141106n5ee44e57k93936aa8def7ff06@mail.gmail.com>
References: <bbaeab100808141106n5ee44e57k93936aa8def7ff06@mail.gmail.com>
Message-ID: <75EEB94A-1256-4E47-B6FB-BF325A2505C4@python.org>

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

On Aug 14, 2008, at 2:06 PM, Brett Cannon wrote:

> But I honestly think this discussion should wait until after we go
> final with 2.6/3.0. Once that happens and we are all not running
> around trying to get a release out, then we should start from the
> ground up and re-evaluate what we need to change. That includes the
> workflow in the issue tracker, how the buildbots are used, what our
> expected best practices are, cleaning up the test suite, how serious
> we are about moving to a distributed VCS, whether we want a PQM, do we
> want code reviews, etc. But I really think we should be putting the
> time in now to b3 and working towards hitting final before we delve
> into this lengthy conversation.

Thanks for the nice summary Brett.  I completely agree with you that  
any changes in process should happen after 2.6/3.0.  I'll now go back  
to harassing people old skool. :)

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSKR3lXEjvBPtnXfVAQLA2AQAkQZHoL4YH8Di+hKzq3nVdJXazSJPL1Va
5xFnobMmrjKYnvfIK1N50Vg/9pSzxLXVvU1OMYsJdoUnXq1NXaleBIfJbjdMtck5
9CULBncXnokD6IioUI410xhJIXsn/39Xw2INVGiO9GwHy9Y9NlkaEs7xvh8uOkP0
yC8P8+Phu6s=
=/bFZ
-----END PGP SIGNATURE-----

From gustavo at niemeyer.net  Thu Aug 14 20:33:56 2008
From: gustavo at niemeyer.net (Gustavo Niemeyer)
Date: Thu, 14 Aug 2008 15:33:56 -0300
Subject: [python-committers] improving our code quality [my summary of
	the "PQM" thread]
In-Reply-To: <bbaeab100808141106n5ee44e57k93936aa8def7ff06@mail.gmail.com>
References: <bbaeab100808141106n5ee44e57k93936aa8def7ff06@mail.gmail.com>
Message-ID: <643d90130808141133u256d9520ta2f71a4f6f8f47f0@mail.gmail.com>

Hey Brett,

> There is also the PQM suggestion to make sure we always at least
> have some general sanity in the code base. But a PQM system would
> probably only work once the test suite is not flaky anymore as
> having some typo in a comment be rejected because test_kqueue failed
> again is not going to go over well with most people.

That's true, but these tests should actually be disabled or fixed.
There's no point in having a test that everyone finds "ok" to have
it broken.

> And that also goes for OS-specific failures on a platform I am not
> running on. Honestly the PQM system probably wouldn't be necessary
> if people just ran the entire test suite before a checkin. And if

The reason to use PQM is precisely so that your commit *does* break
when you create breakage in a platform you're not running on.  Even
though you might not care about breaking someone else's environment,
I believe it's in the best interest of everyone that this doesn't
ever happen in the main line of development.

Note that I'm playing devil's advocate here.  Just like everyone else,
I do enjoy being able to commit straight to the repository and seeing
my changes there.  On the other hand, in a complex environment where
several developers and multiple platforms are involved, the only way
to bring constant stability in is to penalize those that cause breakage.

-- 
Gustavo Niemeyer
http://niemeyer.net

From gustavo at niemeyer.net  Thu Aug 14 21:27:25 2008
From: gustavo at niemeyer.net (Gustavo Niemeyer)
Date: Thu, 14 Aug 2008 16:27:25 -0300
Subject: [python-committers] PQM?
In-Reply-To: <48A4680A.7080202@v.loewis.de>
References: <4838EA2D.7060402@jcea.es> <48A1DA1A.7090103@v.loewis.de>
	<4F0CDE78-146A-493B-BD7D-7D67291E2799@python.org>
	<1218667291.22748.12.camel@fsol>
	<E0530C6F-0330-43E4-B134-0D24EB5AB0CF@python.org>
	<48A38669.4050204@cheimes.de>
	<ca471dc20808132116v6cec6150kdb06d3d19904f7ff@mail.gmail.com>
	<74C813D9-64BD-448F-B6EF-A0387F111F0C@python.org>
	<643d90130808140936h408567cevf61168f8567eaa7@mail.gmail.com>
	<48A4680A.7080202@v.loewis.de>
Message-ID: <643d90130808141227l28d5fafjf904afa188d5c57a@mail.gmail.com>

Hey Martin,

>> What exactly is the "doesnt' scale" issue in this case?
>
> I don't actually know PQM, but from what I hear, it appears that
> PQM can't run tests for a single patch on all of Solaris, Linux,
> Windows, and OS X before accepting it. Instead, PQM will run the
> tests on the same machine it runs on itself, and only on that
> machine.

We actually have PQM setup to work in multiple machines for the same
commit, since we have to ensure that the same source code passes
all tests in a number of platform versions.  I don't personally know in
which platforms PQM runs.

In any case, I'm not suggesting Python should use PQM-the-implementation.
Maybe it's too complex for what is necessary, or too simple, or not portable
enough, or whatever.   At this point, I'm only trying to point out that if you
want stability on platforms that differ from the local one in which a developer
run the test suite on, you must block the merges that will break the other
platforms.

Even though a bit obvious, this idea is still not very popular nowadays
because for a long time, not merging broken code meant not keeping
evolving source code under revision control.  This doesn't have to be
true now.  Developers may evolve their code in a broken way for a long
time before integrating in a main line of development, and consequently
without creating breakage for others, and blocking releases.

-- 
Gustavo Niemeyer
http://niemeyer.net

From barry at python.org  Fri Aug 15 00:00:48 2008
From: barry at python.org (Barry Warsaw)
Date: Thu, 14 Aug 2008 18:00:48 -0400
Subject: [python-committers] PQM?
In-Reply-To: <48A4424E.3000600@cheimes.de>
References: <4838EA2D.7060402@jcea.es>
	<4884581F.8010201@jcea.es>	<bbaeab100807211116g4df70dc1o81b1075a88282c93@mail.gmail.com>	<1BDCADF2-F6EE-4824-80BF-68CB1760CA7B@python.org>	<loom.20080811T095014-204@post.gmane.org>	<2F883F29-DAD8-4D4D-948D-DDAD872EB2A4@python.org>	<6D041763-67AC-4213-AF2B-4AFBB991C699@python.org>	<48A114EB.3090801@v.loewis.de>	<e69d3ed20808112308n2ed1739fv3ecb79e2fa1de279@mail.gmail.com>	<48A12D81.1040309@v.loewis.de>	<e69d3ed20808112354t6cb1a55esbc90126b573fb18b@mail.gmail.com>	<48A13DFA.3080504@v.loewis.de>	<557787AE-51CD-49EB-B16F-C22F45B9F51E@python.org>	<48A1DA1A.7090103@v.loewis.de>	<4F0CDE78-146A-493B-BD7D-7D67291E2799@python.org>	<1218667291.22748.12.camel@fsol>
	<E0530C6F-0330-43E4-B134-0D24EB5AB0CF@python.org>
	<48A38669.4050204@cheimes.de>
	<8D25F11C-2E17-44F9-932E-E8E2831EAF47@python.org>
	<48A4424E.3000600@cheimes.de>
Message-ID: <0A75F3C5-F1EB-4A61-9183-0E4E228159EB@python.org>

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

On Aug 14, 2008, at 10:33 AM, Christian Heimes wrote:

> By the way the guys are totally awesome, dude. :)

I agree wholeheartedly!

>> That's what branches are for.  I really strongly feel that the  
>> mainlines (by which I mean the branches we cut releases from)  
>> should always be in a releasable state.  We should never be  
>> committing broken tests to these mainlines.  If you spot a problem  
>> you can't fix, create a branch and commit the broken test there,  
>> and ask for help with that branch.  The mainline isn't (IMHO) the  
>> place for that.
>> You're right that it will slow us down, but only on the mainline.   
>> That's a good thing, especially if it buys you high quality.
>
> Sticking to our own rules would also buy us quality ... Let's not  
> add new features to our code base during the beta phase, please.  
> Although the addition of multiprocessing had some merit, we  
> shouldn't to the same mistake twice.

That wouldn't have helped.  multiprocessing was added during the alpha  
phase.

> Perhaps we could adopt a release plan similar to Ubuntu. They have  
> releases with cool, new and bleeding edge stuff followed by a  
> release that focuses on stability and long term support. Python 2.6  
> and especially 3.0 are releases with new features. What do you think  
> about focusing on stability and long time support for 2.7 and 3.1?  
> 2.7 might be the last version of the 2.x series and we sure gonna  
> have to fix lots of issues in the 3.x series until it's matured.

If we did this, I think it should be less than 18 months between  
releases.  But I also fear that there will be too much pressure to add  
new features anyway.

I remember at some distant Python conference, Guido asked the  
audience, how many people feel Python is changing too fast, and then  
how many people feel it's missing an important feature.  IIRC, the  
show of hands was about equal.

all-features-except-mine-are-unimportant-ly y'rs,
- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSKSrEXEjvBPtnXfVAQJ+SAP/Q6I0kypLk+iECBgocGxRxOCJF02ghutD
ivALZxZBLB1pF4XeF4Q5R9OPjY37lg6uUwamCf+FUadvyG8u7wOXpUP+0VCB/7VP
XW2kfDc9NxwF8YQ+1etdT76PwYwCjN5i0bu0FVSiRy6zhlh4v/VzGqchLcrIidsr
GaQ/vb0ZNVs=
=9jzj
-----END PGP SIGNATURE-----

From solipsis at pitrou.net  Fri Aug 15 00:01:07 2008
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Fri, 15 Aug 2008 00:01:07 +0200
Subject: [python-committers] ubuntu release plan
In-Reply-To: <48A4424E.3000600@cheimes.de>
References: <4838EA2D.7060402@jcea.es> <4884581F.8010201@jcea.es>
	<bbaeab100807211116g4df70dc1o81b1075a88282c93@mail.gmail.com>
	<1BDCADF2-F6EE-4824-80BF-68CB1760CA7B@python.org>
	<loom.20080811T095014-204@post.gmane.org>
	<2F883F29-DAD8-4D4D-948D-DDAD872EB2A4@python.org>
	<6D041763-67AC-4213-AF2B-4AFBB991C699@python.org>
	<48A114EB.3090801@v.loewis.de>
	<e69d3ed20808112308n2ed1739fv3ecb79e2fa1de279@mail.gmail.com>
	<48A12D81.1040309@v.loewis.de>
	<e69d3ed20808112354t6cb1a55esbc90126b573fb18b@mail.gmail.com>
	<48A13DFA.3080504@v.loewis.de>
	<557787AE-51CD-49EB-B16F-C22F45B9F51E@python.org>
	<48A1DA1A.7090103@v.loewis.de>
	<4F0CDE78-146A-493B-BD7D-7D67291E2799@python.org>
	<1218667291.22748.12.camel@fsol>
	<E0530C6F-0330-43E4-B134-0D24EB5AB0CF@python.org>
	<48A38669.4050204@cheimes.de>
	<8D25F11C-2E17-44F9-932E-E8E2831EAF47@python.org>
	<48A4424E.3000600@cheimes.de>
Message-ID: <1218751267.5572.29.camel@fsol>

Le jeudi 14 ao?t 2008 ? 16:33 +0200, Christian Heimes a ?crit :
> Perhaps we could adopt a release plan similar to Ubuntu. They have 
> releases with cool, new and bleeding edge stuff followed by a release 
> that focuses on stability and long term support.

Ubuntu's sophisticated release plan is certainly justified by its
business model, and the desire to both appeal to the open source people
and the corporate people without creating two different distributions.

I don't think Python has the same business requirements (neither does it
have marketing and commercial teams), and having differentiated releases
sounds like unwarranted complication.

Just my two non-Canonical cents of course!



From barry at python.org  Fri Aug 15 00:03:11 2008
From: barry at python.org (Barry Warsaw)
Date: Thu, 14 Aug 2008 18:03:11 -0400
Subject: [python-committers] PQM?
In-Reply-To: <643d90130808140936h408567cevf61168f8567eaa7@mail.gmail.com>
References: <4838EA2D.7060402@jcea.es> <48A13DFA.3080504@v.loewis.de>
	<557787AE-51CD-49EB-B16F-C22F45B9F51E@python.org>
	<48A1DA1A.7090103@v.loewis.de>
	<4F0CDE78-146A-493B-BD7D-7D67291E2799@python.org>
	<1218667291.22748.12.camel@fsol>
	<E0530C6F-0330-43E4-B134-0D24EB5AB0CF@python.org>
	<48A38669.4050204@cheimes.de>
	<ca471dc20808132116v6cec6150kdb06d3d19904f7ff@mail.gmail.com>
	<74C813D9-64BD-448F-B6EF-A0387F111F0C@python.org>
	<643d90130808140936h408567cevf61168f8567eaa7@mail.gmail.com>
Message-ID: <85545D69-7299-4212-8B5B-56FF672C3FBA@python.org>

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

On Aug 14, 2008, at 12:36 PM, Gustavo Niemeyer wrote:

> Hey Barry,
>
> First, let me thank you for taking the energy to express many  
> interesting
> points in that discussion.

Hi Gustavo!

> We're actually adopting a PQM-based approach *precisely* because we  
> have
> to maintain a code base in multiple versions of the same platform,  
> and thus
> can't be sure that the tests will continue working just by running  
> the suite in
> our own environments.   In this case PQM will help precisely because  
> running
> tests locally "doesn't scale", which is why I'm a bit surprised by the
> straightforward agreement on the point above.

That's an important, different dimension that hasn't come up before.   
Thanks for pointing that out.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSKSrn3EjvBPtnXfVAQJZJwP8CbUmIevDoLy98dvY9+tnPMmGnWSeiRG6
xNxF+uRmXDh1xrCTd7jCJym5eFWnjQ+Y4uRU5EsFyjUpNVSlKcRcv3nb51usAsuw
/oLz6wOEvp6A9rtjR6/EnATeHGAAl506eGSkuJ1yYH8Z6FCsQj7za4rNw4M846E9
dkqPI5hRUUE=
=XTsv
-----END PGP SIGNATURE-----

From jnoller at gmail.com  Fri Aug 15 00:16:31 2008
From: jnoller at gmail.com (Jesse Noller)
Date: Thu, 14 Aug 2008 18:16:31 -0400
Subject: [python-committers] PQM?
In-Reply-To: <0A75F3C5-F1EB-4A61-9183-0E4E228159EB@python.org>
References: <4838EA2D.7060402@jcea.es> <4884581F.8010201@jcea.es>
	<bbaeab100807211116g4df70dc1o81b1075a88282c93@mail.gmail.com>
	<1BDCADF2-F6EE-4824-80BF-68CB1760CA7B@python.org>
	<loom.20080811T095014-204@post.gmane.org>
	<2F883F29-DAD8-4D4D-948D-DDAD872EB2A4@python.org>
	<6D041763-67AC-4213-AF2B-4AFBB991C699@python.org>
	<48A114EB.3090801@v.loewis.de>
	<e69d3ed20808112308n2ed1739fv3ecb79e2fa1de279@mail.gmail.com>
	<48A12D81.1040309@v.loewis.de>
	<e69d3ed20808112354t6cb1a55esbc90126b573fb18b@mail.gmail.com>
	<48A13DFA.3080504@v.loewis.de>
	<557787AE-51CD-49EB-B16F-C22F45B9F51E@python.org>
	<48A1DA1A.7090103@v.loewis.de>
	<4F0CDE78-146A-493B-BD7D-7D67291E2799@python.org>
	<1218667291.22748.12.camel@fsol>
	<E0530C6F-0330-43E4-B134-0D24EB5AB0CF@python.org>
	<48A38669.4050204@cheimes.de>
	<8D25F11C-2E17-44F9-932E-E8E2831EAF47@python.org>
	<48A4424E.3000600@cheimes.de>
	<0A75F3C5-F1EB-4A61-9183-0E4E228159EB@python.org>
Message-ID: <358D64D4-77BD-4535-BEA4-1F0C5FEFE51D@gmail.com>



On Aug 14, 2008, at 6:00 PM, Barry Warsaw <barry at python.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Aug 14, 2008, at 10:33 AM, Christian Heimes wrote:
>
>> By the way the guys are totally awesome, dude. :)
>
> I agree wholeheartedly!
>
>>> That's what branches are for.  I really strongly feel that the  
>>> mainlines (by which I mean the branches we cut releases from)  
>>> should always be in a releasable state.  We should never be  
>>> committing broken tests to these mainlines.  If you spot a problem  
>>> you can't fix, create a branch and commit the broken test there,  
>>> and ask for help with that branch.  The mainline isn't (IMHO) the  
>>> place for that.
>>> You're right that it will slow us down, but only on the mainline.   
>>> That's a good thing, especially if it buys you high quality.
>>
>> Sticking to our own rules would also buy us quality ... Let's not  
>> add new features to our code base during the beta phase, please.  
>> Although the addition of multiprocessing had some merit, we  
>> shouldn't to the same mistake twice.
>
> That wouldn't have helped.  multiprocessing was added during the  
> alpha phase.

Yup - it went in during alpha, and I underestimated the amount of  
work, which won't happen again.

Stunning revelation - getting everything right cross platform is hard.

Note, mp was not the only late-stage addition, there were other core  
language (non package) things in flux as well

>
>> Perhaps we could adopt a release plan similar to Ubuntu. They have  
>> releases with cool, new and bleeding edge stuff followed by a  
>> release that focuses on stability and long term support. Python 2.6  
>> and especially 3.0 are releases with new features. What do you  
>> think about focusing on stability and long time support for 2.7 and  
>> 3.1? 2.7 might be the last version of the 2.x series and we sure  
>> gonna have to fix lots of issues in the 3.x series until it's  
>> matured.
>
> If we did this, I think it should be less than 18 months between  
> releases.  But I also fear that there will be too much pressure to  
> add new features anyway.
>
> I remember at some distant Python conference, Guido asked the  
> audience, how many people feel Python is changing too fast, and then  
> how many people feel it's missing an important feature.  IIRC, the  
> show of hands was about equal.
>
> all-features-except-mine-are-unimportant-ly y'rs,
> - -Barry
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (Darwin)
>
> iQCVAwUBSKSrEXEjvBPtnXfVAQJ+SAP/Q6I0kypLk+iECBgocGxRxOCJF02ghutD
> ivALZxZBLB1pF4XeF4Q5R9OPjY37lg6uUwamCf+FUadvyG8u7wOXpUP+0VCB/7VP
> XW2kfDc9NxwF8YQ+1etdT76PwYwCjN5i0bu0FVSiRy6zhlh4v/VzGqchLcrIidsr
> GaQ/vb0ZNVs=
> =9jzj
> -----END PGP SIGNATURE-----
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> http://mail.python.org/mailman/listinfo/python-committers

From barry at python.org  Fri Aug 15 00:27:29 2008
From: barry at python.org (Barry Warsaw)
Date: Thu, 14 Aug 2008 18:27:29 -0400
Subject: [python-committers] PQM?
In-Reply-To: <358D64D4-77BD-4535-BEA4-1F0C5FEFE51D@gmail.com>
References: <4838EA2D.7060402@jcea.es> <4884581F.8010201@jcea.es>
	<bbaeab100807211116g4df70dc1o81b1075a88282c93@mail.gmail.com>
	<1BDCADF2-F6EE-4824-80BF-68CB1760CA7B@python.org>
	<loom.20080811T095014-204@post.gmane.org>
	<2F883F29-DAD8-4D4D-948D-DDAD872EB2A4@python.org>
	<6D041763-67AC-4213-AF2B-4AFBB991C699@python.org>
	<48A114EB.3090801@v.loewis.de>
	<e69d3ed20808112308n2ed1739fv3ecb79e2fa1de279@mail.gmail.com>
	<48A12D81.1040309@v.loewis.de>
	<e69d3ed20808112354t6cb1a55esbc90126b573fb18b@mail.gmail.com>
	<48A13DFA.3080504@v.loewis.de>
	<557787AE-51CD-49EB-B16F-C22F45B9F51E@python.org>
	<48A1DA1A.7090103@v.loewis.de>
	<4F0CDE78-146A-493B-BD7D-7D67291E2799@python.org>
	<1218667291.22748.12.camel@fsol>
	<E0530C6F-0330-43E4-B134-0D24EB5AB0CF@python.org>
	<48A38669.4050204@cheimes.de>
	<8D25F11C-2E17-44F9-932E-E8E2831EAF47@python.org>
	<48A4424E.3000600@cheimes.de>
	<0A75F3C5-F1EB-4A61-9183-0E4E228159EB@python.org>
	<358D64D4-77BD-4535-BEA4-1F0C5FEFE51D@gmail.com>
Message-ID: <1B93ABA8-311C-4D65-96F3-67FBF816F68A@python.org>

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

On Aug 14, 2008, at 6:16 PM, Jesse Noller wrote:

> Yup - it went in during alpha, and I underestimated the amount of  
> work, which won't happen again.
>
> Stunning revelation - getting everything right cross platform is hard.
>
> Note, mp was not the only late-stage addition, there were other core  
> language (non package) things in flux as well

Let me take this opportunity to explicitly say that I'm not /blaming/  
anybody for this.  I consider the problems we had with the module an  
indication of a systemic, team-wide deficiency.  I greatly appreciate  
you (and others) working so hard to land it and make it work.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSKSxU3EjvBPtnXfVAQK1hwP/R/4bbGPL23mt3cGtG5lW9IzQP47Un9g3
SVloe3BRYU8RtWdX7usXEbpMAH80RASSUPwOOHT1tcsalsro6+iFZMDoqfaHESRs
RlViFVKIxKbPnB/dO4OM1COatIwqc2tuG+Qpe4IIu7RywMW2ClliIMlCLFThCS7Y
lXVzlYJ8sC8=
=pUFl
-----END PGP SIGNATURE-----

From jnoller at gmail.com  Fri Aug 15 00:33:15 2008
From: jnoller at gmail.com (Jesse Noller)
Date: Thu, 14 Aug 2008 18:33:15 -0400
Subject: [python-committers] PQM?
In-Reply-To: <1B93ABA8-311C-4D65-96F3-67FBF816F68A@python.org>
References: <4838EA2D.7060402@jcea.es> <4884581F.8010201@jcea.es>
	<bbaeab100807211116g4df70dc1o81b1075a88282c93@mail.gmail.com>
	<1BDCADF2-F6EE-4824-80BF-68CB1760CA7B@python.org>
	<loom.20080811T095014-204@post.gmane.org>
	<2F883F29-DAD8-4D4D-948D-DDAD872EB2A4@python.org>
	<6D041763-67AC-4213-AF2B-4AFBB991C699@python.org>
	<48A114EB.3090801@v.loewis.de>
	<e69d3ed20808112308n2ed1739fv3ecb79e2fa1de279@mail.gmail.com>
	<48A12D81.1040309@v.loewis.de>
	<e69d3ed20808112354t6cb1a55esbc90126b573fb18b@mail.gmail.com>
	<48A13DFA.3080504@v.loewis.de>
	<557787AE-51CD-49EB-B16F-C22F45B9F51E@python.org>
	<48A1DA1A.7090103@v.loewis.de>
	<4F0CDE78-146A-493B-BD7D-7D67291E2799@python.org>
	<1218667291.22748.12.camel@fsol>
	<E0530C6F-0330-43E4-B134-0D24EB5AB0CF@python.org>
	<48A38669.4050204@cheimes.de>
	<8D25F11C-2E17-44F9-932E-E8E2831EAF47@python.org>
	<48A4424E.3000600@cheimes.de>
	<0A75F3C5-F1EB-4A61-9183-0E4E228159EB@python.org>
	<358D64D4-77BD-4535-BEA4-1F0C5FEFE51D@gmail.com>
	<1B93ABA8-311C-4D65-96F3-67FBF816F68A@python.org>
Message-ID: <DFDF9348-1378-4ABB-B221-5B7CFC7BC933@gmail.com>



On Aug 14, 2008, at 6:27 PM, Barry Warsaw <barry at python.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Aug 14, 2008, at 6:16 PM, Jesse Noller wrote:
>
>> Yup - it went in during alpha, and I underestimated the amount of  
>> work, which won't happen again.
>>
>> Stunning revelation - getting everything right cross platform is  
>> hard.
>>
>> Note, mp was not the only late-stage addition, there were other  
>> core language (non package) things in flux as well
>
> Let me take this opportunity to explicitly say that I'm not / 
> blaming/ anybody for this.  I consider the problems we had with the  
> module an indication of a systemic, team-wide deficiency.  I greatly  
> appreciate you (and others) working so hard to land it and make it  
> work.
>
> - -Barry

I know no one is throwing blame around barry, I just still bad for  
causing the traing to jump the tracks.

Given my own experience - I'm pro "a different scm ala bzr/git that  
makes branching and merging first class citizens"

>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (Darwin)
>
> iQCVAwUBSKSxU3EjvBPtnXfVAQK1hwP/R/4bbGPL23mt3cGtG5lW9IzQP47Un9g3
> SVloe3BRYU8RtWdX7usXEbpMAH80RASSUPwOOHT1tcsalsro6+iFZMDoqfaHESRs
> RlViFVKIxKbPnB/dO4OM1COatIwqc2tuG+Qpe4IIu7RywMW2ClliIMlCLFThCS7Y
> lXVzlYJ8sC8=
> =pUFl
> -----END PGP SIGNATURE-----

From lists at cheimes.de  Fri Aug 15 00:35:59 2008
From: lists at cheimes.de (Christian Heimes)
Date: Fri, 15 Aug 2008 00:35:59 +0200
Subject: [python-committers] ubuntu release plan
In-Reply-To: <1218751267.5572.29.camel@fsol>
References: <4838EA2D.7060402@jcea.es>
	<4884581F.8010201@jcea.es>	<bbaeab100807211116g4df70dc1o81b1075a88282c93@mail.gmail.com>	<1BDCADF2-F6EE-4824-80BF-68CB1760CA7B@python.org>	<loom.20080811T095014-204@post.gmane.org>	<2F883F29-DAD8-4D4D-948D-DDAD872EB2A4@python.org>	<6D041763-67AC-4213-AF2B-4AFBB991C699@python.org>	<48A114EB.3090801@v.loewis.de>	<e69d3ed20808112308n2ed1739fv3ecb79e2fa1de279@mail.gmail.com>	<48A12D81.1040309@v.loewis.de>	<e69d3ed20808112354t6cb1a55esbc90126b573fb18b@mail.gmail.com>	<48A13DFA.3080504@v.loewis.de>	<557787AE-51CD-49EB-B16F-C22F45B9F51E@python.org>	<48A1DA1A.7090103@v.loewis.de>	<4F0CDE78-146A-493B-BD7D-7D67291E2799@python.org>	<1218667291.22748.12.camel@fsol>	<E0530C6F-0330-43E4-B134-0D24EB5AB0CF@python.org>	<48A38669.4050204@cheimes.de>	<8D25F11C-2E17-44F9-932E-E8E2831EAF47@python.org>	<48A4424E.3000600@cheimes.de>
	<1218751267.5572.29.camel@fsol>
Message-ID: <48A4B34F.9090003@cheimes.de>

Antoine Pitrou wrote:
> Ubuntu's sophisticated release plan is certainly justified by its
> business model, and the desire to both appeal to the open source people
> and the corporate people without creating two different distributions.
> 
> I don't think Python has the same business requirements (neither does it
> have marketing and commercial teams), and having differentiated releases
> sounds like unwarranted complication.

IMHO the PSF and Python core development crew doesn't have a business 
plan at all. By business plan I'm referring to making money with Python 
directly. As far as I know most core developers are working on Python 
beause it's fun. Some developers like Guido are paid by their employers 
to work on Python as part of their job.

Just a crazy idea ... Maybe it's time to make the next step toward 
professionalizing Python. Python is more and more becoming important for 
companies. They have to rely upon a stable and solid Python interpreter. 
  Perhaps some companies are willing to pay the PSF. In return the PSF 
could hire some developer to work on Python full time. A couple of 
months ago one well known core developer expressed his interest in a 
paid job. A crew of three to four full time developers could make a huge 
difference.

> Just my two non-Canonical cents of course!

Nice pun :)

Christian

From lists at cheimes.de  Fri Aug 15 00:38:59 2008
From: lists at cheimes.de (Christian Heimes)
Date: Fri, 15 Aug 2008 00:38:59 +0200
Subject: [python-committers] PQM?
In-Reply-To: <1B93ABA8-311C-4D65-96F3-67FBF816F68A@python.org>
References: <4838EA2D.7060402@jcea.es>
	<bbaeab100807211116g4df70dc1o81b1075a88282c93@mail.gmail.com>
	<1BDCADF2-F6EE-4824-80BF-68CB1760CA7B@python.org>
	<loom.20080811T095014-204@post.gmane.org>
	<2F883F29-DAD8-4D4D-948D-DDAD872EB2A4@python.org>
	<6D041763-67AC-4213-AF2B-4AFBB991C699@python.org>
	<48A114EB.3090801@v.loewis.de>
	<e69d3ed20808112308n2ed1739fv3ecb79e2fa1de279@mail.gmail.com>
	<48A12D81.1040309@v.loewis.de>
	<e69d3ed20808112354t6cb1a55esbc90126b573fb18b@mail.gmail.com>
	<48A13DFA.3080504@v.loewis.de>
	<557787AE-51CD-49EB-B16F-C22F45B9F51E@python.org>
	<48A1DA1A.7090103@v.loewis.de>
	<4F0CDE78-146A-493B-BD7D-7D67291E2799@python.org>
	<1218667291.22748.12.camel@fsol>
	<E0530C6F-0330-43E4-B134-0D24EB5AB0CF@python.org>
	<48A38669.4050204@cheimes.de>
	<8D25F11C-2E17-44F9-932E-E8E2831EAF47@python.org>
	<48A4424E.3000600@cheimes.de>
	<0A75F3C5-F1EB-4A61-9183-0E4E228159EB@python.org>
	<358D64D4-77BD-4535-BEA4-1F0C5FEFE51D@gmail.com>
	<1B93ABA8-311C-4D65-96F3-67FBF816F68A@python.org>
Message-ID: <48A4B403.4070901@cheimes.de>

Barry Warsaw wrote:
> Let me take this opportunity to explicitly say that I'm not /blaming/ 
> anybody for this.  I consider the problems we had with the module an 
> indication of a systemic, team-wide deficiency.  I greatly appreciate 
> you (and others) working so hard to land it and make it work.

Hey! Somebody is reading my mind here ... By any chance are you 
telepathic? *g*

From facundobatista at gmail.com  Fri Aug 15 04:48:49 2008
From: facundobatista at gmail.com (Facundo Batista)
Date: Thu, 14 Aug 2008 23:48:49 -0300
Subject: [python-committers] improving our code quality [my summary of
	the "PQM" thread]
In-Reply-To: <bbaeab100808141106n5ee44e57k93936aa8def7ff06@mail.gmail.com>
References: <bbaeab100808141106n5ee44e57k93936aa8def7ff06@mail.gmail.com>
Message-ID: <e04bdf310808141948w1510cbeel50153a9ea77dadc2@mail.gmail.com>

2008/8/14 Brett Cannon <brett at python.org>:

> But I honestly think this discussion should wait until after we go
> final with 2.6/3.0. Once that happens and we are all not running

Thanks Brett for this. I started to write some responses... and then I
realized I agree with you here, it's better to wait for the release,
and then rethink some processes.

> around trying to get a release out, then we should start from the
> ground up and re-evaluate what we need to change. That includes the
> workflow in the issue tracker, how the buildbots are used, what our
> expected best practices are, cleaning up the test suite, how serious
> we are about moving to a distributed VCS, whether we want a PQM, do we
> want code reviews, etc. But I really think we should be putting the

Don't forget the issues tracker. I think it's an awesome tool (the bug
tracking in general, roundup in particular), but I think it could be
improved.

In particular, I hate the state of some bugs where some discussion is
in place, a decission needs to be taken, but the discussion fades out,
nobody takes that decision (normally because the people thinks that
they don't know enough of that domain), and then the bug just stalls.
And, if you pick up that bug six month later, or three year later, you
lose twenty minutes reading the whole discussion, and then realize
that neither you have the expertise to get a decision, and skip to the
next bug.

In the last Python Bug Day, in Argentina this happened a lot: people
digged and digged through the bugs, losing one or two hours before
they get to something solvable (but yet not so easy).

Don't know how to solve this, and I'm pretty sure I'm not pointing out
all the problems: just don't forget to include this in the list.

Thanks again!

-- 
. Facundo

Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/

From anthonybaxter at gmail.com  Fri Aug 15 05:10:25 2008
From: anthonybaxter at gmail.com (Anthony Baxter)
Date: Fri, 15 Aug 2008 13:10:25 +1000
Subject: [python-committers] ubuntu release plan
In-Reply-To: <48A4B34F.9090003@cheimes.de>
References: <4838EA2D.7060402@jcea.es> <48A1DA1A.7090103@v.loewis.de>
	<4F0CDE78-146A-493B-BD7D-7D67291E2799@python.org>
	<1218667291.22748.12.camel@fsol>
	<E0530C6F-0330-43E4-B134-0D24EB5AB0CF@python.org>
	<48A38669.4050204@cheimes.de>
	<8D25F11C-2E17-44F9-932E-E8E2831EAF47@python.org>
	<48A4424E.3000600@cheimes.de> <1218751267.5572.29.camel@fsol>
	<48A4B34F.9090003@cheimes.de>
Message-ID: <e69d3ed20808142010t4b318f63h86bd961afdb5aa0f@mail.gmail.com>

What would this professionalisation get us that we don't have now? As
far as I can see, the biggest hole at the moment (as always) is with
people to trawl the tracker and triage bug reports and patches.

On Fri, Aug 15, 2008 at 8:35 AM, Christian Heimes <lists at cheimes.de> wrote:
> Antoine Pitrou wrote:
>>
>> Ubuntu's sophisticated release plan is certainly justified by its
>> business model, and the desire to both appeal to the open source people
>> and the corporate people without creating two different distributions.
>>
>> I don't think Python has the same business requirements (neither does it
>> have marketing and commercial teams), and having differentiated releases
>> sounds like unwarranted complication.
>
> IMHO the PSF and Python core development crew doesn't have a business plan
> at all. By business plan I'm referring to making money with Python directly.
> As far as I know most core developers are working on Python beause it's fun.
> Some developers like Guido are paid by their employers to work on Python as
> part of their job.
>
> Just a crazy idea ... Maybe it's time to make the next step toward
> professionalizing Python. Python is more and more becoming important for
> companies. They have to rely upon a stable and solid Python interpreter.
>  Perhaps some companies are willing to pay the PSF. In return the PSF could
> hire some developer to work on Python full time. A couple of months ago one
> well known core developer expressed his interest in a paid job. A crew of
> three to four full time developers could make a huge difference.
>
>> Just my two non-Canonical cents of course!
>
> Nice pun :)
>
> Christian
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> http://mail.python.org/mailman/listinfo/python-committers
>

From steve at holdenweb.com  Fri Aug 15 06:17:38 2008
From: steve at holdenweb.com (Steve Holden)
Date: Fri, 15 Aug 2008 00:17:38 -0400
Subject: [python-committers] ubuntu release plan
In-Reply-To: <e69d3ed20808142010t4b318f63h86bd961afdb5aa0f@mail.gmail.com>
References: <4838EA2D.7060402@jcea.es>
	<48A1DA1A.7090103@v.loewis.de>	<4F0CDE78-146A-493B-BD7D-7D67291E2799@python.org>	<1218667291.22748.12.camel@fsol>	<E0530C6F-0330-43E4-B134-0D24EB5AB0CF@python.org>	<48A38669.4050204@cheimes.de>	<8D25F11C-2E17-44F9-932E-E8E2831EAF47@python.org>	<48A4424E.3000600@cheimes.de>
	<1218751267.5572.29.camel@fsol>	<48A4B34F.9090003@cheimes.de>
	<e69d3ed20808142010t4b318f63h86bd961afdb5aa0f@mail.gmail.com>
Message-ID: <48A50362.6090204@holdenweb.com>

My preferred planning strategy is to decide on the goals and then try to 
work out how to achieve them. The PSF will take direction from its 
members and from active developers. But Christian is right about the 
absence of a business plan.

Perhaps when the current release phase is over we need to have a serious 
discussion about other things the PSF can do to support more effective 
development. *Before* we get into the next releases!

If we could get good paid help to massage the tracker that might help, 
but it might not be possible. Given an expressed need from a majority of 
the community I would do what I can to support improvements in the 
development process. It's important, and it would be nice to see closer 
involvement between PSF and developers.

The main thing that's missing right not is the necessary consensus to 
start investing time and money.

regards
  Steve

Anthony Baxter wrote:
> What would this professionalisation get us that we don't have now? As
> far as I can see, the biggest hole at the moment (as always) is with
> people to trawl the tracker and triage bug reports and patches.
> 
> On Fri, Aug 15, 2008 at 8:35 AM, Christian Heimes <lists at cheimes.de> wrote:
>> Antoine Pitrou wrote:
>>> Ubuntu's sophisticated release plan is certainly justified by its
>>> business model, and the desire to both appeal to the open source people
>>> and the corporate people without creating two different distributions.
>>>
>>> I don't think Python has the same business requirements (neither does it
>>> have marketing and commercial teams), and having differentiated releases
>>> sounds like unwarranted complication.
>> IMHO the PSF and Python core development crew doesn't have a business plan
>> at all. By business plan I'm referring to making money with Python directly.
>> As far as I know most core developers are working on Python beause it's fun.
>> Some developers like Guido are paid by their employers to work on Python as
>> part of their job.
>>
>> Just a crazy idea ... Maybe it's time to make the next step toward
>> professionalizing Python. Python is more and more becoming important for
>> companies. They have to rely upon a stable and solid Python interpreter.
>>  Perhaps some companies are willing to pay the PSF. In return the PSF could
>> hire some developer to work on Python full time. A couple of months ago one
>> well known core developer expressed his interest in a paid job. A crew of
>> three to four full time developers could make a huge difference.
>>
>>> Just my two non-Canonical cents of course!
>> Nice pun :)
>>
>> Christian
>> _______________________________________________
>> python-committers mailing list
>> python-committers at python.org
>> http://mail.python.org/mailman/listinfo/python-committers
>>
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> http://mail.python.org/mailman/listinfo/python-committers
> 
> 
> .
> 


-- 
Steve Holden        +1 571 484 6266   +1 800 494 3119
Holden Web LLC              http://www.holdenweb.com/


From lists at cheimes.de  Fri Aug 15 10:42:13 2008
From: lists at cheimes.de (Christian Heimes)
Date: Fri, 15 Aug 2008 10:42:13 +0200
Subject: [python-committers] ubuntu release plan
In-Reply-To: <e69d3ed20808142010t4b318f63h86bd961afdb5aa0f@mail.gmail.com>
References: <4838EA2D.7060402@jcea.es> <48A1DA1A.7090103@v.loewis.de>	
	<4F0CDE78-146A-493B-BD7D-7D67291E2799@python.org>	
	<1218667291.22748.12.camel@fsol>	
	<E0530C6F-0330-43E4-B134-0D24EB5AB0CF@python.org>	
	<48A38669.4050204@cheimes.de>	
	<8D25F11C-2E17-44F9-932E-E8E2831EAF47@python.org>	
	<48A4424E.3000600@cheimes.de> <1218751267.5572.29.camel@fsol>	
	<48A4B34F.9090003@cheimes.de>
	<e69d3ed20808142010t4b318f63h86bd961afdb5aa0f@mail.gmail.com>
Message-ID: <48A54165.4010103@cheimes.de>

Anthony Baxter wrote:
> What would this professionalisation get us that we don't have now? As
> far as I can see, the biggest hole at the moment (as always) is with
> people to trawl the tracker and triage bug reports and patches.

It would get us one or some developers who can work 8+ hours a day, five 
days a week. A paid developer could do all crummy jobs like closing 
bugs. A paid release manager could dedicate more time to take care of 
things. I strongly believe that two full time developers can make a 
difference by providing a better infrastructure for the rest of us.

I blindly assume that non of us is going to say "Give me bucks or I 
won't code any more". But our economy is going through a recession, 
everything is getting more expensive by the day. A constant income would 
allow some guys to code without them worrying about money.
For example we have several talented students in our midst. Let's tap 
into their potential by hiring them. They could use their talent to our 
benefits instead of earning money through internships or side jobs.

Christian

PS: No, I'm not trying to get me a paid job here. I've already got a 
great and well paid one. *g*

From barry at python.org  Fri Aug 15 14:51:32 2008
From: barry at python.org (Barry Warsaw)
Date: Fri, 15 Aug 2008 08:51:32 -0400
Subject: [python-committers] PQM?
In-Reply-To: <48A4B403.4070901@cheimes.de>
References: <4838EA2D.7060402@jcea.es>
	<bbaeab100807211116g4df70dc1o81b1075a88282c93@mail.gmail.com>
	<1BDCADF2-F6EE-4824-80BF-68CB1760CA7B@python.org>
	<loom.20080811T095014-204@post.gmane.org>
	<2F883F29-DAD8-4D4D-948D-DDAD872EB2A4@python.org>
	<6D041763-67AC-4213-AF2B-4AFBB991C699@python.org>
	<48A114EB.3090801@v.loewis.de>
	<e69d3ed20808112308n2ed1739fv3ecb79e2fa1de279@mail.gmail.com>
	<48A12D81.1040309@v.loewis.de>
	<e69d3ed20808112354t6cb1a55esbc90126b573fb18b@mail.gmail.com>
	<48A13DFA.3080504@v.loewis.de>
	<557787AE-51CD-49EB-B16F-C22F45B9F51E@python.org>
	<48A1DA1A.7090103@v.loewis.de>
	<4F0CDE78-146A-493B-BD7D-7D67291E2799@python.org>
	<1218667291.22748.12.camel@fsol>
	<E0530C6F-0330-43E4-B134-0D24EB5AB0CF@python.org>
	<48A38669.4050204@cheimes.de>
	<8D25F11C-2E17-44F9-932E-E8E2831EAF47@python.org>
	<48A4424E.3000600@cheimes.de>
	<0A75F3C5-F1EB-4A61-9183-0E4E228159EB@python.org>
	<358D64D4-77BD-4535-BEA4-1F0C5FEFE51D@gmail.com>
	<1B93ABA8-311C-4D65-96F3-67FBF816F68A@python.org> <48A4B4
	03.4070901@cheimes.de>
Message-ID: <D4899480-6710-49BD-8694-644CEB3B98F9@python.org>

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

On Aug 14, 2008, at 6:38 PM, Christian Heimes wrote:

> Barry Warsaw wrote:
>> Let me take this opportunity to explicitly say that I'm not / 
>> blaming/ anybody for this.  I consider the problems we had with the  
>> module an indication of a systemic, team-wide deficiency.  I  
>> greatly appreciate you (and others) working so hard to land it and  
>> make it work.
>
> Hey! Somebody is reading my mind here ... By any chance are you  
> telepathic? *g*

I /knew/ you were going to ask that!
- -B

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSKV71XEjvBPtnXfVAQKg+AP/WRponsGCPBhJNUZeQlVs0YW+dnVVCOtF
NhSh2Q0IiCzu+zeS38HoEN1GdGGE2IMboOyESdwpWRKX9BGHDrA5U/3wISu8vAof
dN3qUgdmK4Fhcui5S76tP3rGcXxhEjwBEClAO2oeVm1RvXq0EVZTtOzdFHrhb+NN
YSAnY7LMiBg=
=pm3i
-----END PGP SIGNATURE-----

From amk at amk.ca  Fri Aug 15 16:54:56 2008
From: amk at amk.ca (A.M. Kuchling)
Date: Fri, 15 Aug 2008 10:54:56 -0400
Subject: [python-committers] improving our code quality [my summary
	of	the "PQM" thread]
In-Reply-To: <e04bdf310808141948w1510cbeel50153a9ea77dadc2@mail.gmail.com>
References: <bbaeab100808141106n5ee44e57k93936aa8def7ff06@mail.gmail.com>
	<e04bdf310808141948w1510cbeel50153a9ea77dadc2@mail.gmail.com>
Message-ID: <20080815145456.GA8802@amk-desktop.matrixgroup.net>

On Thu, Aug 14, 2008 at 11:48:49PM -0300, Facundo Batista wrote:
> And, if you pick up that bug six month later, or three year later, you
> lose twenty minutes reading the whole discussion, and then realize
> that neither you have the expertise to get a decision, and skip to the
> next bug.
 ...
> Don't know how to solve this, and I'm pretty sure I'm not pointing out
> all the problems: just don't forget to include this in the list.

Should we add a 'needsreview' or 'ready-for-review' keyword that could
be marked on such bugs?  People could check for it before diving into
a bug, and the mythical reviewer could use it too.

--amk

From jnoller at gmail.com  Fri Aug 15 17:06:29 2008
From: jnoller at gmail.com (Jesse Noller)
Date: Fri, 15 Aug 2008 11:06:29 -0400
Subject: [python-committers] improving our code quality [my summary
	of	the "PQM" thread]
In-Reply-To: <20080815145456.GA8802@amk-desktop.matrixgroup.net>
References: <bbaeab100808141106n5ee44e57k93936aa8def7ff06@mail.gmail.com>
	<e04bdf310808141948w1510cbeel50153a9ea77dadc2@mail.gmail.com>
	<20080815145456.GA8802@amk-desktop.matrixgroup.net>
Message-ID: <2E2C5110-3EE5-4F98-B76D-B591F3D2FB02@gmail.com>



On Aug 15, 2008, at 10:54 AM, "A.M. Kuchling" <amk at amk.ca> wrote:

> On Thu, Aug 14, 2008 at 11:48:49PM -0300, Facundo Batista wrote:
>> And, if you pick up that bug six month later, or three year later,  
>> you
>> lose twenty minutes reading the whole discussion, and then realize
>> that neither you have the expertise to get a decision, and skip to  
>> the
>> next bug.
> ...
>> Don't know how to solve this, and I'm pretty sure I'm not pointing  
>> out
>> all the problems: just don't forget to include this in the list.
>
> Should we add a 'needsreview' or 'ready-for-review' keyword that could
> be marked on such bugs?  People could check for it before diving into
> a bug, and the mythical reviewer could use it too.
>

Would it be possible / make sense to tie this more tightly to the code  
review application guido put together?

Perhaps a patch set to needsreview gets an automatic ticket / upload  
to the codereview app?

I'm just thinking that we have a good code review app and a good  
ticket system, maybe we just need to use the code review system more

-Jesse

From facundobatista at gmail.com  Fri Aug 15 17:53:25 2008
From: facundobatista at gmail.com (Facundo Batista)
Date: Fri, 15 Aug 2008 12:53:25 -0300
Subject: [python-committers] improving our code quality [my summary of
	the "PQM" thread]
In-Reply-To: <20080815145456.GA8802@amk-desktop.matrixgroup.net>
References: <bbaeab100808141106n5ee44e57k93936aa8def7ff06@mail.gmail.com>
	<e04bdf310808141948w1510cbeel50153a9ea77dadc2@mail.gmail.com>
	<20080815145456.GA8802@amk-desktop.matrixgroup.net>
Message-ID: <e04bdf310808150853u4a6672f7l9603a3d7596c06f7@mail.gmail.com>

2008/8/15 A.M. Kuchling <amk at amk.ca>:

> Should we add a 'needsreview' or 'ready-for-review' keyword that could
> be marked on such bugs?  People could check for it before diving into
> a bug, and the mythical reviewer could use it too.

*Maybe*. It'd be the fourth keyword there.

But I don't want to start populating that option, and reach the same
issue we have now with "Resolution", without fixing first that issue.

(I'm deliberately trying to avoid getting into how to fix that, we
should leave this for after the releases...)

Regards,

-- 
. Facundo

Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/

From skip at pobox.com  Fri Aug 15 18:37:00 2008
From: skip at pobox.com (skip at pobox.com)
Date: Fri, 15 Aug 2008 11:37:00 -0500
Subject: [python-committers] improving our code quality [my summary of
 the "PQM" thread]
In-Reply-To: <2E2C5110-3EE5-4F98-B76D-B591F3D2FB02@gmail.com>
References: <bbaeab100808141106n5ee44e57k93936aa8def7ff06@mail.gmail.com>
	<e04bdf310808141948w1510cbeel50153a9ea77dadc2@mail.gmail.com>
	<20080815145456.GA8802@amk-desktop.matrixgroup.net>
	<2E2C5110-3EE5-4F98-B76D-B591F3D2FB02@gmail.com>
Message-ID: <18597.45228.446907.958333@montanaro-dyndns-org.local>


    Jesse> Would it be possible / make sense to tie this more tightly to the
    Jesse> code review application guido put together?

Drifting a bit far afield, but are we using Guido's tool (Rietveld)?  If
not, maybe the BDFL should put his BBDF (Big Benevolent Dictator's Foot)
down and decree no more releases until it's part of the Python development
tool chain. <0.5 wink>

Skip

From fredrik at pythonware.com  Fri Aug 15 19:06:27 2008
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Fri, 15 Aug 2008 19:06:27 +0200
Subject: [python-committers] improving our code quality [my summary of
	the "PQM" thread]
In-Reply-To: <18597.45228.446907.958333@montanaro-dyndns-org.local>
References: <bbaeab100808141106n5ee44e57k93936aa8def7ff06@mail.gmail.com>
	<e04bdf310808141948w1510cbeel50153a9ea77dadc2@mail.gmail.com>
	<20080815145456.GA8802@amk-desktop.matrixgroup.net>
	<2E2C5110-3EE5-4F98-B76D-B591F3D2FB02@gmail.com>
	<18597.45228.446907.958333@montanaro-dyndns-org.local>
Message-ID: <368a5cd50808151006q1ead4793jcecdcf6286e7a997@mail.gmail.com>

>    Jesse> Would it be possible / make sense to tie this more tightly to the
>    Jesse> code review application guido put together?
>
> Drifting a bit far afield, but are we using Guido's tool (Rietveld)?  If
> not, maybe the BDFL should put his BBDF (Big Benevolent Dictator's Foot)
> down and decree no more releases until it's part of the Python development
> tool chain. <0.5 wink>

I would still like to hear from someone who's used both Rietveld and
the older (and from what I can tell more widely used) Review Board.

</F>

From skip at pobox.com  Fri Aug 15 19:26:43 2008
From: skip at pobox.com (skip at pobox.com)
Date: Fri, 15 Aug 2008 12:26:43 -0500
Subject: [python-committers] improving our code quality [my summary of
 the "PQM" thread]
In-Reply-To: <368a5cd50808151006q1ead4793jcecdcf6286e7a997@mail.gmail.com>
References: <bbaeab100808141106n5ee44e57k93936aa8def7ff06@mail.gmail.com>
	<e04bdf310808141948w1510cbeel50153a9ea77dadc2@mail.gmail.com>
	<20080815145456.GA8802@amk-desktop.matrixgroup.net>
	<2E2C5110-3EE5-4F98-B76D-B591F3D2FB02@gmail.com>
	<18597.45228.446907.958333@montanaro-dyndns-org.local>
	<368a5cd50808151006q1ead4793jcecdcf6286e7a997@mail.gmail.com>
Message-ID: <18597.48211.153740.841378@montanaro-dyndns-org.local>


    Fredrik> I would still like to hear from someone who's used both
    Fredrik> Rietveld and the older (and from what I can tell more widely
    Fredrik> used) Review Board.

Good point.  A bit to Python-focused in my note.

Skip

From martin at v.loewis.de  Fri Aug 15 19:56:30 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Fri, 15 Aug 2008 19:56:30 +0200
Subject: [python-committers] improving our code quality [my summary	of
 the "PQM" thread]
In-Reply-To: <2E2C5110-3EE5-4F98-B76D-B591F3D2FB02@gmail.com>
References: <bbaeab100808141106n5ee44e57k93936aa8def7ff06@mail.gmail.com>	<e04bdf310808141948w1510cbeel50153a9ea77dadc2@mail.gmail.com>	<20080815145456.GA8802@amk-desktop.matrixgroup.net>
	<2E2C5110-3EE5-4F98-B76D-B591F3D2FB02@gmail.com>
Message-ID: <48A5C34E.5020608@v.loewis.de>

> I'm just thinking that we have a good code review app and a good ticket
> system, maybe we just need to use the code review system more

Rietveld will already send reviews into the bug tracker, assuming you
make the bug tracker a reviewer, or otherwise a message recipient.

Regards,
Martin

From alexandre at peadrop.com  Fri Aug 15 21:30:26 2008
From: alexandre at peadrop.com (Alexandre Vassalotti)
Date: Fri, 15 Aug 2008 15:30:26 -0400
Subject: [python-committers] ubuntu release plan
In-Reply-To: <48A54165.4010103@cheimes.de>
References: <4838EA2D.7060402@jcea.es> <1218667291.22748.12.camel@fsol>
	<E0530C6F-0330-43E4-B134-0D24EB5AB0CF@python.org>
	<48A38669.4050204@cheimes.de>
	<8D25F11C-2E17-44F9-932E-E8E2831EAF47@python.org>
	<48A4424E.3000600@cheimes.de> <1218751267.5572.29.camel@fsol>
	<48A4B34F.9090003@cheimes.de>
	<e69d3ed20808142010t4b318f63h86bd961afdb5aa0f@mail.gmail.com>
	<48A54165.4010103@cheimes.de>
Message-ID: <acd65fa20808151230t4092d5bsdb28d8bef6cb8b1f@mail.gmail.com>

On Fri, Aug 15, 2008 at 4:42 AM, Christian Heimes <lists at cheimes.de> wrote:
> I blindly assume that non of us is going to say "Give me bucks or I won't
> code any more". But our economy is going through a recession, everything is
> getting more expensive by the day. A constant income would allow some guys
> to code without them worrying about money.
> For example we have several talented students in our midst. Let's tap into
> their potential by hiring them. They could use their talent to our benefits
> instead of earning money through internships or side jobs.

To me, that sounds much like Google Summer of Code, except with more
weight on the hiree's shoulders to perform well. The main difference
would probably be that a PSF sponsored developer wouldn't be focused
on a single project.

-- Alexandre

From richardjones at optushome.com.au  Mon Aug 18 04:30:15 2008
From: richardjones at optushome.com.au (Richard Jones)
Date: Mon, 18 Aug 2008 12:30:15 +1000
Subject: [python-committers] Revoking Richard Emslie's privs
In-Reply-To: <bbaeab100808031519p589eb723u7fde72cf07f00794@mail.gmail.com>
References: <bbaeab100808031519p589eb723u7fde72cf07f00794@mail.gmail.com>
Message-ID: <200808181230.15461.richardjones@optushome.com.au>

On Mon, 4 Aug 2008, Brett Cannon wrote:
> Another person requesting their privs be removed.

There's no sense in me having commit privs these days either. Haven't used 
them since NFS! Please revoke.


    Richard

From g.brandl at gmx.net  Mon Aug 18 22:57:35 2008
From: g.brandl at gmx.net (Georg Brandl)
Date: Mon, 18 Aug 2008 22:57:35 +0200
Subject: [python-committers] Revoking Richard Emslie's privs
In-Reply-To: <200808181230.15461.richardjones@optushome.com.au>
References: <bbaeab100808031519p589eb723u7fde72cf07f00794@mail.gmail.com>
	<200808181230.15461.richardjones@optushome.com.au>
Message-ID: <g8cnlk$g8s$1@ger.gmane.org>

Richard Jones schrieb:
> On Mon, 4 Aug 2008, Brett Cannon wrote:
>> Another person requesting their privs be removed.
> 
> There's no sense in me having commit privs these days either. Haven't used 
> them since NFS! Please revoke.

Done.

Georg


From barry at python.org  Thu Aug 21 02:48:12 2008
From: barry at python.org (Barry Warsaw)
Date: Wed, 20 Aug 2008 20:48:12 -0400
Subject: [python-committers] Fw: Releasing beta 3's tonight
Message-ID: <20080820204812.4c398796@resist.wooz.org>

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


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIrLtN2YZpQepbvXERAoX8AJ0St0a0I/kH88Idrjnn161SmxeBvACfdojR
C7K2CQVBaD+JYMh8BN8j1xE=
=Esr9
-----END PGP SIGNATURE-----
-------------- next part --------------
An embedded message was scrubbed...
From: Barry Warsaw <barry at python.org>
Subject: Releasing beta 3's tonight
Date: Wed, 20 Aug 2008 18:45:06 -0400
Size: 1208
URL: <http://mail.python.org/pipermail/python-committers/attachments/20080820/e0c33578/attachment.eml>

From barry at python.org  Thu Aug 21 05:10:18 2008
From: barry at python.org (Barry Warsaw)
Date: Wed, 20 Aug 2008 23:10:18 -0400
Subject: [python-committers] Trunk and 3.0 branch are now open
Message-ID: <20080820231018.1cde4c23@resist.wooz.org>

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

The releases are done.  Thanks, both the 3.0 branch and the trunk are now open
for commits.

- -Barry
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIrNyb2YZpQepbvXERAq/WAJwMG1nc/7K3D+fgXFOnoYbJ2bmJoQCeNa3Z
ssE/3G13S9YLkXUHt3ivJhY=
=I46l
-----END PGP SIGNATURE-----

From brett at python.org  Thu Aug 21 05:24:47 2008
From: brett at python.org (Brett Cannon)
Date: Wed, 20 Aug 2008 20:24:47 -0700
Subject: [python-committers] Trunk and 3.0 branch are now open
In-Reply-To: <20080820231018.1cde4c23@resist.wooz.org>
References: <20080820231018.1cde4c23@resist.wooz.org>
Message-ID: <bbaeab100808202024g5ce1ce5ft516091782a2e36ce@mail.gmail.com>

On Wed, Aug 20, 2008 at 8:10 PM, Barry Warsaw <barry at python.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> The releases are done.  Thanks, both the 3.0 branch and the trunk are now open
> for commits.
>

Since the next step is release candidates, I have two questions:

1. Do commits now require a code review?
2. Should we make release blockers out of anything we think must be
fixed before final?

-Brett

From barry at python.org  Thu Aug 21 14:27:04 2008
From: barry at python.org (Barry Warsaw)
Date: Thu, 21 Aug 2008 08:27:04 -0400
Subject: [python-committers] Trunk and 3.0 branch are now open
In-Reply-To: <bbaeab100808202024g5ce1ce5ft516091782a2e36ce@mail.gmail.com>
References: <20080820231018.1cde4c23@resist.wooz.org>
	<bbaeab100808202024g5ce1ce5ft516091782a2e36ce@mail.gmail.com>
Message-ID: <F8F3C416-B538-4B6A-92C3-361BD4956153@python.org>

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

On Aug 20, 2008, at 11:24 PM, Brett Cannon wrote:

> On Wed, Aug 20, 2008 at 8:10 PM, Barry Warsaw <barry at python.org>  
> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> The releases are done.  Thanks, both the 3.0 branch and the trunk  
>> are now open
>> for commits.
>>
>
> Since the next step is release candidates, I have two questions:
>
> 1. Do commits now require a code review?

Ideally, all comments are reviewed <wink>, but I think the current  
arrangement will have to work for the rc's.  I'd say be even more  
careful about the changes you introduce in behavior or API.

> 2. Should we make release blockers out of anything we think must be
> fixed before final?

Yes.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSK1fGHEjvBPtnXfVAQJHvQP/TUKrvwiIoJOLXjEMwtMTjl2+9sH9d4PH
4iQ7BBJTPUiSW+t31H+G535huJiC0JBOLRziS1r+cO2KNtF66CkpnRrlDK9M/nbz
Uhe1CxYfMQLinMvIuPoGiT11qu5uNej8XackQX5v/OX1I96vKenaC/TFuELSvua/
gRGP6K/vS6o=
=0rBw
-----END PGP SIGNATURE-----

From guido at python.org  Thu Aug 21 18:29:55 2008
From: guido at python.org (Guido van Rossum)
Date: Thu, 21 Aug 2008 09:29:55 -0700
Subject: [python-committers] Trunk and 3.0 branch are now open
In-Reply-To: <F8F3C416-B538-4B6A-92C3-361BD4956153@python.org>
References: <20080820231018.1cde4c23@resist.wooz.org>
	<bbaeab100808202024g5ce1ce5ft516091782a2e36ce@mail.gmail.com>
	<F8F3C416-B538-4B6A-92C3-361BD4956153@python.org>
Message-ID: <ca471dc20808210929g6d7cbeach69facdb9640d0387@mail.gmail.com>

[Brett]
>> Since the next step is release candidates, I have two questions:
>>
>> 1. Do commits now require a code review?

[Barry]
> Ideally, all comments are reviewed <wink>, but I think the current
> arrangement will have to work for the rc's.  I'd say be even more careful
> about the changes you introduce in behavior or API.

I think it makes sense now to require review by another committer for
*all* changes until the final release, even trivial fixes of obvious
bugs, with the exception of doc fixes. This would also allow touching
up docstrings and comments without review. To enforce this, how about
the requirement of adding "Reviewed by <username>" to the checkin
comment?

[Brett]
>> 2. Should we make release blockers out of anything we think must be
>> fixed before final?

[Barry]
> Yes.

Right. This means that anything that's not a release blocker should be
considered okay to leave unfixed. There are enough release blockers
left that we'll have our hands full fixing just those.

We need to start triaging bugs with the goal of a rock solid release
-- many bugs found at this point (or long known) are better left
unfixed rather than destabilizing the release. There is no exact
science to this, no hard and fast set of rules -- but before deciding
to fix a bug, please consult at least one other committer, and when it
doubt, mail the list. It's much better to leave some bugs unfixed than
to stumble badly in the rush towards one more fix.

As for anything that smells like a feature, Just Say No!

And finally: merges from the trunk to 3.0 should be done *very*
carefully. I request that whoever does a merge runs the full test
suite (with --uall) before committing.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From brett at python.org  Thu Aug 21 20:30:15 2008
From: brett at python.org (Brett Cannon)
Date: Thu, 21 Aug 2008 11:30:15 -0700
Subject: [python-committers] Trunk and 3.0 branch are now open
In-Reply-To: <ca471dc20808210929g6d7cbeach69facdb9640d0387@mail.gmail.com>
References: <20080820231018.1cde4c23@resist.wooz.org>
	<bbaeab100808202024g5ce1ce5ft516091782a2e36ce@mail.gmail.com>
	<F8F3C416-B538-4B6A-92C3-361BD4956153@python.org>
	<ca471dc20808210929g6d7cbeach69facdb9640d0387@mail.gmail.com>
Message-ID: <bbaeab100808211130s308ee3bdkbeed86d8aaba61c0@mail.gmail.com>

On Thu, Aug 21, 2008 at 9:29 AM, Guido van Rossum <guido at python.org> wrote:
> [Brett]
>>> Since the next step is release candidates, I have two questions:
>>>
>>> 1. Do commits now require a code review?
>
> [Barry]
>> Ideally, all comments are reviewed <wink>, but I think the current
>> arrangement will have to work for the rc's.  I'd say be even more careful
>> about the changes you introduce in behavior or API.
>
> I think it makes sense now to require review by another committer for
> *all* changes until the final release, even trivial fixes of obvious
> bugs, with the exception of doc fixes. This would also allow touching
> up docstrings and comments without review. To enforce this, how about
> the requirement of adding "Reviewed by <username>" to the checkin
> comment?
>

That's what I was thinking; either real name or username, which ever
you remember at the time. Since we don't have a way to flag an issue
with a patch as needing a committer review, either we just continually
check for release blockers with patches or we email here saying what
issues have a patch ready and just need a second review.

-Brett

From musiccomposition at gmail.com  Thu Aug 21 21:00:59 2008
From: musiccomposition at gmail.com (Benjamin Peterson)
Date: Thu, 21 Aug 2008 14:00:59 -0500
Subject: [python-committers] Fwd:  Trunk and 3.0 branch are now open
In-Reply-To: <1afaf6160808211158i598840c5wcd6dd3796270af82@mail.gmail.com>
References: <20080820231018.1cde4c23@resist.wooz.org>
	<bbaeab100808202024g5ce1ce5ft516091782a2e36ce@mail.gmail.com>
	<F8F3C416-B538-4B6A-92C3-361BD4956153@python.org>
	<ca471dc20808210929g6d7cbeach69facdb9640d0387@mail.gmail.com>
	<bbaeab100808211130s308ee3bdkbeed86d8aaba61c0@mail.gmail.com>
	<1afaf6160808211158i598840c5wcd6dd3796270af82@mail.gmail.com>
Message-ID: <1afaf6160808211200q12587c7at6ae4dcc246a6015@mail.gmail.com>

---------- Forwarded message ----------
From: Benjamin Peterson <musiccomposition at gmail.com>
Date: Thu, Aug 21, 2008 at 1:58 PM
Subject: Re: [python-committers] Trunk and 3.0 branch are now open
To: Brett Cannon <brett at python.org>


On Thu, Aug 21, 2008 at 1:30 PM, Brett Cannon <brett at python.org> wrote:
>
> That's what I was thinking; either real name or username, which ever
> you remember at the time. Since we don't have a way to flag an issue
> with a patch as needing a committer review, either we just continually
> check for release blockers with patches or we email here saying what
> issues have a patch ready and just need a second review.

I've created a keyword, "needs review", that we can attach to issues.
Then you use the "Needs review" query [1] to find them.

[1] http://bugs.python.org/issue?%40search_text=&title=&%40columns=title&id=&%40columns=id&creation=&creator=&activity=&%40columns=activity&%40sort=activity&actor=&nosy=&type=&components=&versions=&dependencies=&assignee=&keywords=8&priority=&status=1&%40columns=status&resolution=&%40group=&%40pagesize=50&%40startwith=0&%40sortdir=on&%40queryname=Needs+review&%40old-queryname=&%40action=search
>
> -Brett
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> http://mail.python.org/mailman/listinfo/python-committers
>



--
Cheers,
Benjamin Peterson
"There's no place like 127.0.0.1."



-- 
Cheers,
Benjamin Peterson
"There's no place like 127.0.0.1."

From guido at python.org  Thu Aug 21 22:18:44 2008
From: guido at python.org (Guido van Rossum)
Date: Thu, 21 Aug 2008 13:18:44 -0700
Subject: [python-committers] Fwd: Trunk and 3.0 branch are now open
In-Reply-To: <1afaf6160808211200q12587c7at6ae4dcc246a6015@mail.gmail.com>
References: <20080820231018.1cde4c23@resist.wooz.org>
	<bbaeab100808202024g5ce1ce5ft516091782a2e36ce@mail.gmail.com>
	<F8F3C416-B538-4B6A-92C3-361BD4956153@python.org>
	<ca471dc20808210929g6d7cbeach69facdb9640d0387@mail.gmail.com>
	<bbaeab100808211130s308ee3bdkbeed86d8aaba61c0@mail.gmail.com>
	<1afaf6160808211158i598840c5wcd6dd3796270af82@mail.gmail.com>
	<1afaf6160808211200q12587c7at6ae4dcc246a6015@mail.gmail.com>
Message-ID: <ca471dc20808211318u15eacb39t3ce66567d027263b@mail.gmail.com>

Hm, I can't say how the "needs review" query works...

On Thu, Aug 21, 2008 at 12:00 PM, Benjamin Peterson
<musiccomposition at gmail.com> wrote:
> ---------- Forwarded message ----------
> From: Benjamin Peterson <musiccomposition at gmail.com>
> Date: Thu, Aug 21, 2008 at 1:58 PM
> Subject: Re: [python-committers] Trunk and 3.0 branch are now open
> To: Brett Cannon <brett at python.org>
>
>
> On Thu, Aug 21, 2008 at 1:30 PM, Brett Cannon <brett at python.org> wrote:
>>
>> That's what I was thinking; either real name or username, which ever
>> you remember at the time. Since we don't have a way to flag an issue
>> with a patch as needing a committer review, either we just continually
>> check for release blockers with patches or we email here saying what
>> issues have a patch ready and just need a second review.
>
> I've created a keyword, "needs review", that we can attach to issues.
> Then you use the "Needs review" query [1] to find them.
>
> [1] http://bugs.python.org/issue?%40search_text=&title=&%40columns=title&id=&%40columns=id&creation=&creator=&activity=&%40columns=activity&%40sort=activity&actor=&nosy=&type=&components=&versions=&dependencies=&assignee=&keywords=8&priority=&status=1&%40columns=status&resolution=&%40group=&%40pagesize=50&%40startwith=0&%40sortdir=on&%40queryname=Needs+review&%40old-queryname=&%40action=search
>>
>> -Brett
>> _______________________________________________
>> python-committers mailing list
>> python-committers at python.org
>> http://mail.python.org/mailman/listinfo/python-committers
>>
>
>
>
> --
> Cheers,
> Benjamin Peterson
> "There's no place like 127.0.0.1."
>
>
>
> --
> Cheers,
> Benjamin Peterson
> "There's no place like 127.0.0.1."
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> http://mail.python.org/mailman/listinfo/python-committers
>



-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From brett at python.org  Thu Aug 21 22:30:22 2008
From: brett at python.org (Brett Cannon)
Date: Thu, 21 Aug 2008 13:30:22 -0700
Subject: [python-committers] Fwd: Trunk and 3.0 branch are now open
In-Reply-To: <ca471dc20808211318u15eacb39t3ce66567d027263b@mail.gmail.com>
References: <20080820231018.1cde4c23@resist.wooz.org>
	<bbaeab100808202024g5ce1ce5ft516091782a2e36ce@mail.gmail.com>
	<F8F3C416-B538-4B6A-92C3-361BD4956153@python.org>
	<ca471dc20808210929g6d7cbeach69facdb9640d0387@mail.gmail.com>
	<bbaeab100808211130s308ee3bdkbeed86d8aaba61c0@mail.gmail.com>
	<1afaf6160808211158i598840c5wcd6dd3796270af82@mail.gmail.com>
	<1afaf6160808211200q12587c7at6ae4dcc246a6015@mail.gmail.com>
	<ca471dc20808211318u15eacb39t3ce66567d027263b@mail.gmail.com>
Message-ID: <bbaeab100808211330l2c62f956id54be14bec34ba1@mail.gmail.com>

On Thu, Aug 21, 2008 at 1:18 PM, Guido van Rossum <guido at python.org> wrote:
> Hm, I can't say how the "needs review" query works...
>

You can do the search yourself by going to Search and choosing "needs
review" under the Keyword pull-down.

-Brett

> On Thu, Aug 21, 2008 at 12:00 PM, Benjamin Peterson
> <musiccomposition at gmail.com> wrote:
>> ---------- Forwarded message ----------
>> From: Benjamin Peterson <musiccomposition at gmail.com>
>> Date: Thu, Aug 21, 2008 at 1:58 PM
>> Subject: Re: [python-committers] Trunk and 3.0 branch are now open
>> To: Brett Cannon <brett at python.org>
>>
>>
>> On Thu, Aug 21, 2008 at 1:30 PM, Brett Cannon <brett at python.org> wrote:
>>>
>>> That's what I was thinking; either real name or username, which ever
>>> you remember at the time. Since we don't have a way to flag an issue
>>> with a patch as needing a committer review, either we just continually
>>> check for release blockers with patches or we email here saying what
>>> issues have a patch ready and just need a second review.
>>
>> I've created a keyword, "needs review", that we can attach to issues.
>> Then you use the "Needs review" query [1] to find them.
>>
>> [1] http://bugs.python.org/issue?%40search_text=&title=&%40columns=title&id=&%40columns=id&creation=&creator=&activity=&%40columns=activity&%40sort=activity&actor=&nosy=&type=&components=&versions=&dependencies=&assignee=&keywords=8&priority=&status=1&%40columns=status&resolution=&%40group=&%40pagesize=50&%40startwith=0&%40sortdir=on&%40queryname=Needs+review&%40old-queryname=&%40action=search
>>>
>>> -Brett
>>> _______________________________________________
>>> python-committers mailing list
>>> python-committers at python.org
>>> http://mail.python.org/mailman/listinfo/python-committers
>>>
>>
>>
>>
>> --
>> Cheers,
>> Benjamin Peterson
>> "There's no place like 127.0.0.1."
>>
>>
>>
>> --
>> Cheers,
>> Benjamin Peterson
>> "There's no place like 127.0.0.1."
>> _______________________________________________
>> python-committers mailing list
>> python-committers at python.org
>> http://mail.python.org/mailman/listinfo/python-committers
>>
>
>
>
> --
> --Guido van Rossum (home page: http://www.python.org/~guido/)
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> http://mail.python.org/mailman/listinfo/python-committers
>

From musiccomposition at gmail.com  Thu Aug 21 22:31:32 2008
From: musiccomposition at gmail.com (Benjamin Peterson)
Date: Thu, 21 Aug 2008 15:31:32 -0500
Subject: [python-committers] Fwd: Trunk and 3.0 branch are now open
In-Reply-To: <bbaeab100808211330l2c62f956id54be14bec34ba1@mail.gmail.com>
References: <20080820231018.1cde4c23@resist.wooz.org>
	<bbaeab100808202024g5ce1ce5ft516091782a2e36ce@mail.gmail.com>
	<F8F3C416-B538-4B6A-92C3-361BD4956153@python.org>
	<ca471dc20808210929g6d7cbeach69facdb9640d0387@mail.gmail.com>
	<bbaeab100808211130s308ee3bdkbeed86d8aaba61c0@mail.gmail.com>
	<1afaf6160808211158i598840c5wcd6dd3796270af82@mail.gmail.com>
	<1afaf6160808211200q12587c7at6ae4dcc246a6015@mail.gmail.com>
	<ca471dc20808211318u15eacb39t3ce66567d027263b@mail.gmail.com>
	<bbaeab100808211330l2c62f956id54be14bec34ba1@mail.gmail.com>
Message-ID: <1afaf6160808211331l5245f1e0ke30c85aaaacf3367@mail.gmail.com>

On Thu, Aug 21, 2008 at 3:30 PM, Brett Cannon <brett at python.org> wrote:
> On Thu, Aug 21, 2008 at 1:18 PM, Guido van Rossum <guido at python.org> wrote:
>> Hm, I can't say how the "needs review" query works...
>>
>
> You can do the search yourself by going to Search and choosing "needs
> review" under the Keyword pull-down.

Or you can click "edit" by "Your queries" and select the "Needs review" query.


-- 
Cheers,
Benjamin Peterson
"There's no place like 127.0.0.1."

From brett at python.org  Thu Aug 21 22:31:37 2008
From: brett at python.org (Brett Cannon)
Date: Thu, 21 Aug 2008 13:31:37 -0700
Subject: [python-committers] Fwd: Trunk and 3.0 branch are now open
In-Reply-To: <1afaf6160808211200q12587c7at6ae4dcc246a6015@mail.gmail.com>
References: <20080820231018.1cde4c23@resist.wooz.org>
	<bbaeab100808202024g5ce1ce5ft516091782a2e36ce@mail.gmail.com>
	<F8F3C416-B538-4B6A-92C3-361BD4956153@python.org>
	<ca471dc20808210929g6d7cbeach69facdb9640d0387@mail.gmail.com>
	<bbaeab100808211130s308ee3bdkbeed86d8aaba61c0@mail.gmail.com>
	<1afaf6160808211158i598840c5wcd6dd3796270af82@mail.gmail.com>
	<1afaf6160808211200q12587c7at6ae4dcc246a6015@mail.gmail.com>
Message-ID: <bbaeab100808211331m2dfbb04vb369c9a371a0be68@mail.gmail.com>

On Thu, Aug 21, 2008 at 12:00 PM, Benjamin Peterson
<musiccomposition at gmail.com> wrote:
> ---------- Forwarded message ----------
> From: Benjamin Peterson <musiccomposition at gmail.com>
> Date: Thu, Aug 21, 2008 at 1:58 PM
> Subject: Re: [python-committers] Trunk and 3.0 branch are now open
> To: Brett Cannon <brett at python.org>
>
>
> On Thu, Aug 21, 2008 at 1:30 PM, Brett Cannon <brett at python.org> wrote:
>>
>> That's what I was thinking; either real name or username, which ever
>> you remember at the time. Since we don't have a way to flag an issue
>> with a patch as needing a committer review, either we just continually
>> check for release blockers with patches or we email here saying what
>> issues have a patch ready and just need a second review.
>
> I've created a keyword, "needs review", that we can attach to issues.
> Then you use the "Needs review" query [1] to find them.
>

This will work short-term until after final is out and we discuss how
we want our triage process to go. And it is probably best not to
deselect the "patch" keyword if you do set this keyword; they are not
mutually exclusive.

-Brett

From musiccomposition at gmail.com  Thu Aug 21 22:37:31 2008
From: musiccomposition at gmail.com (Benjamin Peterson)
Date: Thu, 21 Aug 2008 15:37:31 -0500
Subject: [python-committers] Fwd: Trunk and 3.0 branch are now open
In-Reply-To: <bbaeab100808211331m2dfbb04vb369c9a371a0be68@mail.gmail.com>
References: <20080820231018.1cde4c23@resist.wooz.org>
	<bbaeab100808202024g5ce1ce5ft516091782a2e36ce@mail.gmail.com>
	<F8F3C416-B538-4B6A-92C3-361BD4956153@python.org>
	<ca471dc20808210929g6d7cbeach69facdb9640d0387@mail.gmail.com>
	<bbaeab100808211130s308ee3bdkbeed86d8aaba61c0@mail.gmail.com>
	<1afaf6160808211158i598840c5wcd6dd3796270af82@mail.gmail.com>
	<1afaf6160808211200q12587c7at6ae4dcc246a6015@mail.gmail.com>
	<bbaeab100808211331m2dfbb04vb369c9a371a0be68@mail.gmail.com>
Message-ID: <1afaf6160808211337w129e5614h9ce8e2b5e484f5da@mail.gmail.com>

On Thu, Aug 21, 2008 at 3:31 PM, Brett Cannon <brett at python.org> wrote:
> This will work short-term until after final is out and we discuss how
> we want our triage process to go. And it is probably best not to
> deselect the "patch" keyword if you do set this keyword; they are not
> mutually exclusive.

To help out your reviewers, you also might want to put your patch on
Rietveld. I personally prefer using it instead of finding the files I
need to compare the patch to manually and calculating out lines
numbers etc.
>
> -Brett
>



-- 
Cheers,
Benjamin Peterson
"There's no place like 127.0.0.1."

From amauryfa at gmail.com  Thu Aug 28 10:34:26 2008
From: amauryfa at gmail.com (Amaury Forgeot d'Arc)
Date: Thu, 28 Aug 2008 10:34:26 +0200
Subject: [python-committers] python 3.0 compilation warning in
	Objects/stringlib/find.h
Message-ID: <e27efe130808280134n84c747dk7fde5a847505ff71@mail.gmail.com>

Hello,

r65977 was not correctly merged into py3k; I get the following
compilation warning:

Objects/stringlib/find.h:93:36: warning: extra tokens at end of #ifdef directive

And indeed, the line

#ifdef STRINGLIB_WANT_CONTAINS_OBJ && !defined(FROM_BYTEARRAY)

does not seem correct. I suppose the "#ifdef" could be replaced by
"#if defined",
but I'm not sure to understand the code. The symbol seems not to be
defined anywhere...

--
Amaury Forgeot d'Arc

From christian at cheimes.de  Thu Aug 28 13:24:38 2008
From: christian at cheimes.de (Christian Heimes)
Date: Thu, 28 Aug 2008 13:24:38 +0200
Subject: [python-committers] python 3.0 compilation warning
	in	Objects/stringlib/find.h
In-Reply-To: <e27efe130808280134n84c747dk7fde5a847505ff71@mail.gmail.com>
References: <e27efe130808280134n84c747dk7fde5a847505ff71@mail.gmail.com>
Message-ID: <48B68AF6.5050503@cheimes.de>

Amaury Forgeot d'Arc wrote:
> Hello,
> 
> r65977 was not correctly merged into py3k; I get the following
> compilation warning:
> 
> Objects/stringlib/find.h:93:36: warning: extra tokens at end of #ifdef directive
> 
> And indeed, the line
> 
> #ifdef STRINGLIB_WANT_CONTAINS_OBJ && !defined(FROM_BYTEARRAY)
> 
> does not seem correct. I suppose the "#ifdef" could be replaced by
> "#if defined",
> but I'm not sure to understand the code. The symbol seems not to be
> defined anywhere...

At first I thought it's my fault. I added the FROM_BYTEARRAY macro to 
stringlib/find.h and bytearrayobject.c a while ago. It was necessary in 
order to get rid of a compiler warning in bytearrayobject.c. However I 
added the macro only to the trunk.

The code was ported to the py3k branch although it isn't necessary. You 
can safely remove the check for FROM_BYTEARRAY.

Christian