On Wed, Aug 13, 2008 at 4:03 PM, Barry Warsaw <[EMAIL PROTECTED]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Aug 13, 2008, at 6:41 PM, Antoine Pitrou wrote: > >> Le mercredi 13 août 2008 à 18:33 -0400, Barry Warsaw a écrit : >>> >>> Or to adopt tools that help improve reliability. I'm not convinced >>> that the buildbots really do that. A PQM-style approach, while more >>> of a pain for developers because of the serialized landings, would >>> definitely improve things, and there's not nearly as much >>> infrastructure involved to keep humming for old releases. PQM isn't >>> perfect, but I do believe it would help. >> >> What is a "PQM-style approach"? > > 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. >
Ah, OK. > If any of the set of conditions fail, the changeset does not land. This > means that the trunk is always in a releasable state, and we avoid the > problems I run into all the time now, where we have red buildbots on or near > release date. I would dearly love to be able to spin a release at any time > and have a high degree of confidence that what I'm releasing is stable. > Well, it would definitely catch those changes that manage to break ALL the buildbots, but those that only break on the platforms that the developer is not on might just cause pain. > There's a specific implementation of PQM based on the Bazaar revision > control system, available here: https://edge.launchpad.net/pqm > Why am I not surprised that bzr has support for something you are suggesting? =) > PQM is not perfect, nor is it a perfect fit for us. For example, we have > buildbots that run on multiple platforms, while PQM runs on a single > platform. So a vanilla PQM could still miss changes that break only on a > specific operating system. It also doesn't help at all for bugs not covered > by the test suite (well, buildbots don't help there either ;). > > PQM also introduces delays on trunk landing because it serializes commits. > So when things get backed up, it might take a while for your branch to land > on the trunk. > There is also the shift in development style to larger patch sets (assuming your version control system supports patch sets) instead of a lot of incremental commits to the trunk since you might end up with a cascading failure of your commits if you were dependent on an earlier one fails and thus all your subsequent checkins will be rejected. > PQM wouldn't replace the buildbots, but it would greatly improve the quality > of the development branches, IMO. The buildbots would still be useful to > ensure cross-platform quality. Well, another option is to flesh out ``make check`` such that it runs more sanity checks and makes sure the entire test suite is run and passed before a commit is done, basically doing what you are suggesting, but on a local level. -Brett _______________________________________________ python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers