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.
_______________________________________________
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers
