Should Mailman move to Bazaar?

[Zachery Hostens]

On Sat, 05 May 2007 22:39:08 +0200, Mads Kiilerich <mads at kiilerich.com> wrote:
> The Mailman project, led by Barry Warsaw (of Python fame,
> Canonical-employee but fair and unbiased also wrt DVCS), are considering
> moving to Bazaar
> (http://www.mail-archive.com/mailman-developers%40python.org/msg10281.html),
> partly because of the availability of Launchpad hosting
> (http://www.mail-archive.com/mailman-developers%40python.org/msg10322.html).
> 
> Mercurial has come up as an alternative.
> 
> Barry Warsaw asks for more info about Mercurial hosting
> (http://www.mail-archive.com/mailman-developers%40python.org/msg10313.html):
>> > http://marc.info/?l=mercurial&m=117753118122082
> <http://marc.info/?l=mercurial&m=117753118122082>
>>
>> That could be very interesting.  I know that was just a couple of
>> weeks ago, but have you heard of an eta for such hosting?

this i would not consider a weakness of a project.  i dont see svn or even cvs offering hosting of any kind.  granted there are other sites that support those becuase they are the "big guys" ...

a VPS is $20 at most and my <VirtualHost> tag in apache for my mercurial public pullable repo/https  htdigest secured push repo is 15 lines at MOST.  hell i could setup trac & hg repo[s] on a single virtualhost with probably 30 lines at most in httpd.conf and make a small http accessible page to change commiters to each project.

i dont like the idea of crying for free/public/easy-to-use repo hosting as a "up" for a scm product.

bzr is ok but there push/pull mechanism is WAY to slow for me to cope with/handle on any bases.(MY oppinion)

> Barry has problems with yasvn2hg
> (http://www.mail-archive.com/mailman-developers%40python.org/msg10317.html).
> Could/would someone offer him help?  - he probably won't ask for help
> before the choice has been made, and if he can't convert then the choice
> probably won't be Mercurial...

yasvn2hg was just mentioned on the mailing list for the first time a week ago and judging from the repo started not much longer beyond then.  i would have liked to use it but is way to strict (currently) to handle any svn repo other than one obiding by the strict trunk/branches/tags root level directories layout.  If it wasn't for me not touching python in the past 2 years id be willing to dig into it and make it more flexible (which i still may do when i find time.)

I personally would recommend talking to the author for suggestions / offering to help make the script more flexible or even throw a patch or 2 at him.

> Stephen J. Turnbull (from xemacs.org) has problems with the Mercurial
> side of a Tailer-conversion
> (http://www.mail-archive.com/mailman-developers%40python.org/msg10329.html).
> 
> 
> It would be nice if the Mercurial community could help them choosing the
> best DVCS for their need. And it would be even nicer if the system
> running the Mercurial mailing lists was developed using Mercurial.

this is another standpoint i find it bad to come off as.  Matt has worked hard on mercurial, and the community does much enjoy using it.  The hg (or cvs, or svn, or bzr, or git, or *) communities should NOT try persuading anyone into using something that may or may not suite there needs.  every project has its own needs and reasons, and should find the solution that best suites THEM.

Granted.  The community IS here, and IS willing to answer any questions they have about said solution.  The community is NOT here to be asked to go out of their way to say this is THE solution and why you should use us.  we arent a sales team :/.

> An observation:
> 
> It seems like the biggest problem with Mercurial isn't functionality or
> stability or usability but conversion and hosting.

this is probably a problem for most scm's i think.  from what i have seen bzr,hg,git kind of cope well with each other and migrate back and forth easily (enough) from one another.  i dont see any projects for making migration from hg/git/bzr to cvs or svn very easy (then again i haven't looked to much.)  Because hg/bzr/git is the 'new hot solution' is no reason they should have a migration plan for everyone's current problem set in place.

Migrations are never a peice of cake, and no single migration solution fits everyones needs.  everyones repo's are set up differently and require seperate changes/differences to migrations.  hell however you decide to setup your new repo[s]/branches may well as not coincide with your current repo[s] in ANY way shape or form.


Sorry if im coming off a little harsh.  Most of this email (to me) just sounded like a bad plea for 'tell me why i should use hg and fix what i need fixed so we can use it.'  Which isn't how i feel the Open Source community is about.

--
Zachery Hostens