python-committers August 2008

python-committers@python.org

28 participants
10 discussions

Trunk and 3.0 branch are now open
by Barry Warsaw 04 Sep '08

04 Sep '08

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

4 5

python 3.0 compilation warning in Objects/stringlib/find.h
by Amaury Forgeot d'Arc 28 Aug '08

28 Aug '08

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

2 1

Fwd: Trunk and 3.0 branch are now open
by Benjamin Peterson 21 Aug '08

21 Aug '08

---------- Forwarded message ---------- From: Benjamin Peterson <musiccomposition(a)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(a)python.org> On Thu, Aug 21, 2008 at 1:30 PM, Brett Cannon <brett(a)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=&%4… > > -Brett > _______________________________________________ > python-committers mailing list > python-committers(a)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."

3 5

Fw: Releasing beta 3's tonight
by Barry Warsaw 21 Aug '08

21 Aug '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIrLtN2YZpQepbvXERAoX8AJ0St0a0I/kH88Idrjnn161SmxeBvACfdojR C7K2CQVBaD+JYMh8BN8j1xE= =Esr9 -----END PGP SIGNATURE-----

1 0

Revoking Richard Emslie's privs
by Brett Cannon 18 Aug '08

18 Aug '08

Another person requesting their privs be removed. ---------- Forwarded message ---------- From: Richard Emslie <richardemslie(a)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(a)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(a)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(a)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(a)python.org > http://mail.python.org/mailman/listinfo/python-committers >

4 3

Re: [python-committers] [Python-Dev] next beta
by Barry Warsaw 15 Aug '08

15 Aug '08

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

21 62

improving our code quality [my summary of the "PQM" thread]
by Brett Cannon 15 Aug '08

15 Aug '08

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

9 10

Nominate Hirokazu Yamamoto (oceancity) for commit privs.
by Trent Nelson 12 Aug '08

12 Aug '08

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.

7 7

Revoking Matt Fleming's commit privileges
by Brett Cannon 03 Aug '08

03 Aug '08

Just got this email from Matt. ---------- Forwarded message ---------- From: Matt Fleming <mattjfleming(a)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(a)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

1 0

Everyone is now subscribed (and two people to drop)
by Brett Cannon 03 Aug '08

03 Aug '08

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

1 0

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

python-committers August 2008