-----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-----
_______________________________________________
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers
