[python-committers] PQM?

[Guido van Rossum]

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