[python-committers] PQM?

[Barry Warsaw]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Aug 13, 2008, at 10:49 PM, Brett Cannon wrote:

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

That's a downside of PQM, but still, someone's gotta fix the pain.   
Ideally, it would be the developer who committed the broken change.   
The problem of not having access to all the platforms, or not being  
able to debug problems on those platforms is a different issue.

>> 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? =)

Hey, a good tool is a good tool. :)  But really, I think the process  
is the important thing, then find the tools that make that process easy.

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

Yep.  Figure out what you want, then find the tools that fit. :)

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

Hook that into svn commit so that you /have/ to run it, and maybe you  
can convince me. :)

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSKO3nnEjvBPtnXfVAQKMbQP/XSVQ5ACG9JXrl30Jfodg2anrIPYcWjyb
+JCqs0Bbgy6vqeI3h0g5AlsKQbUBRbCXq2tqUVNgWjgWCUoofuU4Uw/2YieJa3Tc
KcIsHeI8YcpnGW5e0ipXEPG/9B9m3T4UVybk8N3LQ7SW8ca6oRZgH7EgKEgmwHD0
SCIMtVDXgQk=
=7ojY
-----END PGP SIGNATURE-----