[Python-Dev] Looking for VCS usage scenarios

[Barry Warsaw]

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

- -Barry

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

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