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