[Mailman-Developers] Should we move to Bazaar?
barry at python.org
Fri May 4 23:20:34 CEST 2007
-----BEGIN PGP SIGNED MESSAGE-----
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
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
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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
-----END PGP SIGNATURE-----
More information about the Mailman-Developers