On Wed, Aug 13, 2008 at 6:12 PM, Christian Heimes christian@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/)