On Wed, Aug 13, 2008 at 4:03 PM, Barry Warsaw email@example.com 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.
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.