[Python-Dev] Looking for VCS usage scenarios (original) (raw)

Barry Warsaw barry at python.org
Thu Nov 6 16:30:20 CET 2008

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

On Nov 5, 2008, at 8:36 PM, Stephen J. Turnbull wrote:

I disagree. This doesn't scale to Python size. For distributed VC to work, somebody has to maintain a repo 24x7. Python has to do this for the trunk; the additional burden for contributed patches is not great. There is no real advantage to having contributors do so, too.[3] Integrators and interested third parties also must keep track of contributor's repo URLs. (Cf. Skip's question about discovering repos.) Not happy stuff.

There's an interesting automation available when hosting branches on
Launchpad and using a patch queue manager (PQM in particular). I
believe this is not quite deployed so I might be speaking out of
class, and it's unlikely that Python would do anything but self-host
its branches (though this doesn't necessarily prevent the following).
Still I will describe this so you see the possibilities.

Launchpad has something call "merge proposals". When a branch is
ready, the original developer creates a merge proposal which is
basically a request for review. The dev can ask for a specific
reviewer (e.g. barry for the email package), or he can ask anyone on
the team for a review. LP doesn't impose a specific workflow, so some
projects require 2 or more reviews for any piece of code, others maybe
1 review, etc.

Let's say I review Stephen's branch to fix a bug in the email
package. I request some changes, Stephen makes them, and now the
branch looks great. I can approve the branch and now neither Stephen
nor I need to do anything in order to get that branch pushed to the
mainline.

This works under the covers as follows: when approved, the branch
details get added to a queue managed by Launchpad. Python.org would
run a PQM that watches this queue. Python's PQM just picks branches
off the top, one by one, and it tries to land them. If any conflicts
arise or tests fail, the branch doesn't merge. Otherwise, it lands
and all the appropriate metadata about the branch (and its associated
bug) gets updated automatically.

This is a nice model for several reasons. It's the bot's
responsibility to do the grunt work of merging, landing, and pushing
new branches to the mainline. Humans only care about developing the
code and reviewing the results. Also, this aligns with something I've
been very interested in from a release manager's POV: I'd like the
mainline branches to always be in a releasable state. We can now
define that releasable state to be "whatever adheres to the bot's
landing rules".

I'm skeptical Python would ever adopt this workflow, if only because
there is technical work that would have to be done (i.e. we'd have to
run the bot). Still, I wanted to explain this so that you could get a
sense of what's possible.

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

iQCVAwUBSRMNjnEjvBPtnXfVAQJHXwP/T6WbEIvWC8OJh8i4UnmHvgj8hbT5tbED 2sQRBHNxrBavwhvENUTAM0n4a8j+jSwof8PszflRbiNLVANYKJ1wWHfevkkPcwL7 mzcgtZqpkijWdJoGOeif04LcjuiYopSSEtPLRC9QdDygwlZmhhvbPFVQ2xvtc6C/ 4DO12JDPICA= =Zn9N -----END PGP SIGNATURE-----

More information about the Python-Dev mailing list