[python-committers] PQM?

[Christian Heimes]

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.