[python-committers] PQM?

Barry Warsaw barry at python.org
Thu Aug 14 06:35:28 CEST 2008


-----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-----


More information about the python-committers mailing list