[python-committers] PQM?

[Brett Cannon]

On Wed, Aug 13, 2008 at 4:03 PM, Barry Warsaw <barry at python.org> 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