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.