[Mailman-Developers] Should we move to Bazaar?

[Barry Warsaw]

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

On May 4, 2007, at 2:21 PM, Stephen J. Turnbull wrote:

> Barry Warsaw writes:
>
>> Is anybody interested in trying to complete the Mercurial
>> conversion?  I can make a bz2-tarball of the svn repository available
>> if you want to give it a shot.  It's about 87MB.
>
> I'll take svn2hg via Tailor, since that's what I'm using anyway for
> XEmacs.

Cool thanks.  To prevent it from getting into the archives, I'll send  
you the url under separate cover.  I'd love to see what you come up  
with.

BTW, I have the answers to hosting questions for Bazaar-on- 
Launchpad.  We can definitely do it, and I'm in the process of  
getting the branches in the current Mailman project on Launchpad  
updated.  They were using the old SF urls, which no longer work.  I'm  
hoping the branches will be updated by sometime next week.

A couple of other points.

Permissions would be managed on a team basis.  What this means is  
that the official mainline branch would be owned by a "Mailman  
Coders" or other special team which I will create.  I'll close  
membership in the team so that only approved devs will have access.   
We can basically invite all those devs that are still active SF devs  
to join this team.  Any team member will be able to create new  
branches, push changes, etc. to the team owned filesystem namespace.

If you're /not/ a team member, you can still make your own branches.   
If you're a Launchpad member, you can even host those branches on  
Launchpad's supermirror, basically by branching from the official  
mainline branch to your local workspace, then pushing your branches  
to Launchpad under the filesystem namespace that your user owns.   
This sounds like it will work great because everyone can start  
hacking on the code immediately, they can publish branches for the  
rest of the community by pushing to Launchpad, we core devs can merge  
in your changes, check them out, etc. but it's up to us to merge them  
into the mainline and commit them back.

An advantage to this is that we only need to verify paperwork for the  
merge into mainline, and you don't have to worry about it at all  
unless and until we want to merge your stuff in.  It's up to us to  
verify the paperwork before we merge.  (Getting rid of the paperwork  
requirement is a different matter.)  But there's absolutely no  
obstacle to you maintaining your own branches for interesting work  
you want to do... and publish.

Another nice thing is that we can set up the supermirror to, er,  
mirror the Subversion trunk, basically giving us a free way to try it  
out.  If we decide to make the switch, we'd simply turn off the  
mirroring and disable the svn trunk on SF.

I propose that no matter which way we go (Mercurial, Bazaar or  
something else), we convert only the trunk.  Let's leave the stable  
2.1 branch on SF under Subversion, but do all new development in the  
dvcs.  It will be a bit more painful to commit fixes across both  
branches (sorry Mark, Tokio!) but that will probably be the case  
fairly soon anyway, as it's unavoidable that the trunk is going to  
diverge (<3.0 cough>).

For the very short term, your first branch of the mainline, and your  
first push to a supermirror branch will be rather slow, with the  
actual time dependent on the speed of your network connection.  The  
problem is that you'll have to pull all the history for 8100+  
revisions to your disk the first time, and you will have to push all  
those revisions back to the supermirror.  However, if you put your  
revs in a bzr repo on your local system (highly recommended), you'll  
only incur this pain once (and even then, I don't know how painful it  
will actually be -- we'll have to see).  bzr repositories make things  
really fast, and the supermirror automatically puts things in a  
repository so subsequent pushes, pulls, and branches can be very fast.

I've been told that Launchpad will soon be addressing this by  
allowing you to "pre-seed" your supermirror branch, and I think,  
doing something like rsync over the full history the first time.   
IOW, this initial speed bump will only affect you the first time, and  
work is actively being done to reduce even this initial speed bump.

Let's give Steve a shot at doing the Mercurial conversion.  We'll  
also set up the Launchpad mirror.  Then we can do some more real  
comparisons and make a decision from there.

Cheers,
- -Barry

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

iQCVAwUBRjujo3EjvBPtnXfVAQLyHAP8C98v6vcgin7G4xBnuui4pGKAqch4v3EP
TORU+PUAiJvepTesJMbAtaz93YIamo+orkkHnnNDgaewqgzguAnbseGPXwMhQ5UP
CnlyYnVxU3C794fkfaxiCZ0ucFayOmfWg6k1L5o0EXVB6orBjpa1h3dkXRPK0Dt4
tttC1wGyWJE=
=q/CV
-----END PGP SIGNATURE-----