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:
taken before it had been done?
doesn't it mean it would have got almost no testing since people are unlikely to test specific branches rather than the "official trunk"?
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.