-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Aug 13, 2008, at 9:12 PM, Christian Heimes 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.
Unfortunately, they're not being solved without PQM either! Really,
we've had to delay releases several times because the branches were
broken across multiple operating systems. Pleading on the mailing
lists doesn't help. Hanging out on irc doesn't help. Having
Benjamin, Georg, and others kicking ass on #python-dev the day of a
release, is great, but it's also asking a lot of them.
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.
That's what branches are for. I really strongly feel that the
mainlines (by which I mean the branches we cut releases from) should
always be in a releasable state. We should never be committing broken
tests to these mainlines. If you spot a problem you can't fix, create
a branch and commit the broken test there, and ask for help with that
branch. The mainline isn't (IMHO) the place for that.
You're right that it will slow us down, but only on the mainline.
That's a good thing, especially if it buys you high quality.
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.
We should be using the same quality assurance early in the cycle that
we do late in the cycle. Realistically, we're never going to switch
to something different when we get to RC.
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.
These are good policies to adopt. I know of many projects that
require one or two positive code reviews for branches to land in the
mainline. Code reviews and PQM augment each other though, they don't
replace each other. We're all human and code reviews will never be
perfect. Some changes have non-local or unexpected effects that only
the test suite will catch. Maybe the test pass on your machine
because of something in your environment that breaks in the PQM
"ideal" environment.
Christian, who still thinks (hopes) that the human mind outperforms
machines when it comes down to important and complex decisions.
It's not us vs. them. I want the machines to do the crappy grunt work
so us humans can do what we do best, being creative and having
fun :). Begging people to fix broken buildbots on release day is
neither.
- -Barry
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)
iQCVAwUBSKO2EnEjvBPtnXfVAQIkzwP/cRwyLdkl27NoB3RYoWHzjv17EqeB+1Ha
sjlZ9cuYtIZG3j7YHd11BoUcpbS5ZIUHq1J9PTVdUGrqNRAdCYIZuppM2XSE95ir
lNj2VSZ0th6g0NeIcPpMTzdNOxp+OJ/np0U+k7zKJOoJl1+HopGJg3+LsO6h/XRs
Ysg1yN9BMAY=
=D6Zz
-----END PGP SIGNATURE-----
_______________________________________________
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers
