[python-committers] improving our code quality [my summary of the "PQM" thread]
facundobatista at gmail.com
Fri Aug 15 04:48:49 CEST 2008
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
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
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.
More information about the python-committers