[python-committers] PQM?

Barry Warsaw barry at python.org
Thu Aug 14 14:39:07 CEST 2008


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Aug 14, 2008, at 5:27 AM, Antoine Pitrou wrote:

>
>> It would be a change in culture for us, that's for sure. The question
>> becomes whether the drop in patch throughput is justified by an
>> increase of patch quality and stability in the code?
>
> Well, let's take the multiprocessing example. The question is:
> - would an a priori review have been able to uncover the most subtle  
> bugs?
> - would someone have done that review at all, and how long would it  
> have
> taken before it had been done?
> - if we had delayed the inclusion of multiprocessing in the mainline,
> doesn't it mean it would have got almost no testing since people are
> unlikely to test specific branches rather than the "official trunk"?
> - isn't the inclusion of multiprocessing itself, even if subtle bugs
> remain, an increase of quality since it gives people a standard and  
> rather
> good package for doing parallel stuff, rather than baking their own
> defective ad-hoc solutions?
>
> The thing I want to point out in the latter item is that measuring  
> quality
> solely by the number of bugs or the stability of a bunch of  
> buildbots is
> wrong (although of course fixing bugs and having green buildbots *is*
> important). Sometimes committing an imperfect patch can be better than
> committing nothing at all.

I think this is a case where PQM might have helped.  Assuming the  
build/test would uncover these subtle bugs, the multiprocessing code  
would not have landed.  You would then probably publish a branch with  
those (failing) changes and rally the help you needed to fix those  
problems.  Then you'd try to land it again.

The workflow would have likely been very similar to what happened for  
this code, except that it would be happening on a branch, not on the  
mainline.  Maybe no one would have been motivated enough to get them  
working if they weren't breaking mainline.  The tradeoff is  
instability in the mainline and uncertainty as to whether the mainline  
is of high enough quality to release.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSKQna3EjvBPtnXfVAQKFgAP9HS2HRbhD5X1SOyRqi6aopmNOYyO216g0
2AL4xintyCvqPJaU8FNkBT4XEM9ayCt39pvpeBFDUWN1t6r2xZ7UR22ye0Ic2aei
otC5dmZFMEtDOjhbqmFQ6YmYs9ZvpvrQ37h01ath4uX2lVjjH/h91m4w6fJ7FYQT
kIT456eW9nU=
=hzTW
-----END PGP SIGNATURE-----


More information about the python-committers mailing list