[python-committers] PQM?

[Antoine Pitrou]

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

Regards

Antoine.