Re: [Mailman-Developers] Should we move to Bazaar?

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Just a quick update on the conversion to Bazaar.

There are a couple of things you can do right now to play with bzr.   
The Launchpad admins have fixed the urls for the two branches hosted  
there.  To check out the Mailman 2.1 bzr mirror of upstream  
Release_2_1-maint branch, do the following:

cd someplace
mkdir mailman-lpnet
cd mailman-lpnet
bzr init-repo .
bzr branch http://bazaar.launchpad.net/~vcs-imports/mailman/2.1

You could also substitute "main" for "2.1" above to get a branch of  
the svn trunk.  My understanding is that the branch mirror on  
Launchpad updates every 6 hours or so, so the lag between commits to  
upstream svn and pulling/merging in changes via bzr shouldn't be too  
bad given the pace of commits.

BTW, I like doing the initial branch in a repo above so that  
subsequent local branches are pretty quick.  The initial branch takes  
me about 8 minutes to pull 972 revisions on a fast US broadband  
connection.

The other option is to use the bzr-svn plugin, but you'll need some  
pretty cutting edge package versions for that.  If you're on Ubuntu  
feisty, you pretty much have what you need: bzr 0.16, bzr-svn 0.3.2,  
and the latest svn Python bindings.

In that case, try this:

cd someplace
mkdir mailman-bzr
cd mailman-bzr
bzr init-repo .
bzr branch http://mailman.svn.sourceforge.net/svnroot/mailman/trunk

This takes me about 70 minutes to pull 6826 revisions on the same  
connection.  You'll get more than you really want or need because the  
bzr-svn plugin can't branch from inside 'trunk'.  I haven't tried  
branching from branches/Release_2_1-maint yet.

The nice thing about this is that you've essentially got your own  
mirror of upstream svn.  You can do your own merging/pulling in this  
repo with no lag.  If you had commit privileges on the upstream svn  
repo, you could do those right in place, without having to go through  
svn (tho I haven't been brave enough yet to try it ;).

Please play with these and let us know what you think.  If/when we  
decide to switch to bzr, we can set the branches up to be more  
convenient for us.

- -Barry

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

iQCVAwUBRkHLlXEjvBPtnXfVAQIVfgP/ehYI0rBmWF+a5F2i/Tu0Mh30IRPYNcKe
rQ/YYtaJj8aotQtPq22Ec85r9u0bTw1CtiyIqFEWN6RsHbMuH1C6gPCCbL1tuSAb
PzbyN98V4glX4HpfJfmeCSNCS+MPX4SQaL6oHzdi2oXUg27BJGa8ynt3R2bcLdgs
h3qRlIKALCU=
=Rw5e
-END PGP SIGNATURE-
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

Re: [Mailman-Developers] Should we move to Bazaar?

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On May 8, 2007, at 3:42 PM, Terri Oda wrote:

> On 7-May-07, at 11:37 AM, Barry Warsaw wrote:
>> Here is my current thinking, and I'd like to know what you all think
>> about this.  Andrew created the mondernize_21_webui branch and
>> applied the xhtml and css patches to it.  We could conceivably keep
>> these changes very conservative, i.e. just u/i and *possibly* the top
>> 3 new features.  Then we'd release this as Mailman 2.2 and rename the
>> really advanced work Mailman 3.0
>
> +1 assuming that this means we can just use CSS directly and don't
> need any weird work-arounds for those old colour settings!   When
> updating the version number makes life that much easier, it's
> definitely time. :)
>
> In the interest of making it happen soonest, I'd be happy if we just
> released just with the new UI rather than trying to choose other
> features at this point, but that's probably just my bias showing
> through.

Andrew makes an alternative suggestion in a separate thread.  I'll  
try to respond there, but I'm leaning in this direction.

- -Barry

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

iQCVAwUBRkEE93EjvBPtnXfVAQJOfwP9FdbiEtToESgrIH/ForOL4bsUo4kWfYSo
yQbwNBXW02IRzZNunBOaJmPZMfme2uzXty/cUSWNFHQOAchBwSYC6sZ45jjSt1FV
Em41+uApM7LMJZG/BV8HtjqQP+qyR/tkGIwtAgg3/o5DIpVSh+nHmrI0sZ1ssUbl
RV47Fx+nSoc=
=8v7v
-END PGP SIGNATURE-
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

Re: [Mailman-Developers] Should we move to Bazaar?

[Terri Oda]

On 7-May-07, at 11:37 AM, Barry Warsaw wrote:
> Here is my current thinking, and I'd like to know what you all think
> about this.  Andrew created the mondernize_21_webui branch and
> applied the xhtml and css patches to it.  We could conceivably keep
> these changes very conservative, i.e. just u/i and *possibly* the top
> 3 new features.  Then we'd release this as Mailman 2.2 and rename the
> really advanced work Mailman 3.0

+1 assuming that this means we can just use CSS directly and don't  
need any weird work-arounds for those old colour settings!   When  
updating the version number makes life that much easier, it's  
definitely time. :)

In the interest of making it happen soonest, I'd be happy if we just  
released just with the new UI rather than trying to choose other  
features at this point, but that's probably just my bias showing  
through.

  Terri



___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

Re: [Mailman-Developers] Should we move to Bazaar?

[Stephen J. Turnbull]

Barry Warsaw writes:

 > On May 5, 2007, at 12:49 PM, Stephen J. Turnbull wrote:
 > 
 > > I'm now a lot less happy with Mercurial than I was a day ago.
 > 
 > Bummer.

Well, Mike (XEmacs's Mercurial champion) accuses Tailor of abusing the
Mercurial APIs.  He has a point, although my worries retain some
validity, I think.

 > I'm about to head up to New York City for the day, so just a  
 > quick note of thanks for taking a look at this.  Once you're done  
 > will we be able to get a bzr branch from Tailor or will we have to do  
 > another import?

I'm not sure what you mean.  I don't think it's a good idea to go
svn->hg->bzr, if that's what you mean; there's some degradation of
metadata in each transition.  I'll give a Tailor svn->bzr conversion a
shot.  Let me know what you want to do about giving "concerned
parties" access to them (I presume you don't want them sitting on a
Googlable webserver at this point).

Please note that no conversion has taken as much as three hours.  One
svn rev per second seems to be the going rate for all of the
conversion tools I've tried, and the initialization from the svn log
takes only a few seconds.

IOW, I can surely make full imports faster than you can evaluate
them.  The question will be preserving or injecting desired
metadata (eg, sensible summary logs, user id mapping), which for most
tools will take some hacking.

 > Please keep us up to date about how it goes.

OK, at this point, I've temporarily given up on Tailor for svn->hg.
There's a locking deadlock (I think) in Mercurial at about r7721, and
it will take some time to diagnose that.

I did get both a full trunk conversion and a "trunk/mailman" only
conversion from the hgsvn tool (which is just a one-way sync, svn to
hg).  hgsvn has the advantage of being a PyPI project.  easy_install
hgsvn if somebody wants to try.  (If you don't have easy_install, you
can get it from http://peak.telecommunity.com/DevCenter/EasyInstall.)

I also tried Eric Hopper's svn2hg (there are a couple of tools by that
name).  It looks well-coded, but it's not ready for general use.

___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

Re: [Mailman-Developers] Should we move to Bazaar?

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On May 6, 2007, at 3:48 PM, Mads Kiilerich wrote:

> Barry Warsaw wrote, On 05/04/2007 03:28 PM:
>>> Mr Mercurial might soon come up with an alternative:
>>> 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?
>
> I asked them and just got a reply from Matt that "hgserve.org now  
> exists",
> http://selenic.com/pipermail/mercurial/2007-May/013105.html - but I
> haven't heard any further details yet.

Cool, thanks Mads.

One of the Launchpad admins is doing a new import of the MM2.1  
branch, and possibly the trunk (though that's lower priority).  This  
will not be a full-history import, but it will sync daily with  
upstream svn.  I'll let you know when it's ready so people can play  
with it.

After talking with them, it seems like the best thing to do is, if we  
decide to switch to bzr, we'll take svn off-line for a bit, do a full- 
history bzr import, then turn svn on read-only and start to develop  
all code on bzr.

- -Barry

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

iQCVAwUBRj9Ir3EjvBPtnXfVAQL0iwQAtgw5uNFKfbARQWM76Y+oIvmL7wJdgI1E
M7PVybyUlL3F2gNsHFsUoOuh/3STrRDyGWno9UKnl2/JGUtEiQgLL+ziAtFopxjQ
ff+lQwNs0p5lnwlKp79uwz9uOLPSjQR7ufkcXlKub6gdc/Gso/o0Jc7JXluDVRsn
va1NQSKKRBY=
=fDH9
-END PGP SIGNATURE-
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

Re: [Mailman-Developers] Should we move to Bazaar?

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On May 5, 2007, at 12:49 PM, Stephen J. Turnbull wrote:

> I'm now a lot less happy with Mercurial than I was a day ago.

Bummer.  I'm about to head up to New York City for the day, so just a  
quick note of thanks for taking a look at this.  Once you're done  
will we be able to get a bzr branch from Tailor or will we have to do  
another import?

Please keep us up to date about how it goes.

- -Barry

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

iQCVAwUBRj9IG3EjvBPtnXfVAQKx7QQAgDLOp5xfQrhnpK80/DQr44GBd2GKQRbj
RCGajy5hxz+PeTrAKvduAZhd0uG3RjUCdKR0hvYYWIfTipt337rcYV2QxElvAuBT
qlXo1b1wfWRadrSARbMUn0Cuvp05pC7NeGsw3HH9tX3fYdjrN7xyHOc1cYVCW7I9
tFGbHdcdtHg=
=P467
-END PGP SIGNATURE-
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

Re: [Mailman-Developers] Should we move to Bazaar?

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On May 5, 2007, at 4:08 AM, Terri Oda wrote:

> I, like Mark, have little to say about dvcs (I've only passingly used
> Bazaar) but I'm happy to learn whatever I need to know.

Excellent.  I think we have consensus for a switch if/when we find a  
dvcs we like.

> However, I would like to say that I hope this discussion doesn't
> dissuade people from doing that UI work right now.  Please please
> please don't wait on this, 'cause if we wait for the Next Big Thing
> we're going to wind up with no updated UI, once again.  Not that I'm
> a cynic. ;)

Here is my current thinking, and I'd like to know what you all think  
about this.  Andrew created the mondernize_21_webui branch and  
applied the xhtml and css patches to it.  We could conceivably keep  
these changes very conservative, i.e. just u/i and *possibly* the top  
3 new features.  Then we'd release this as Mailman 2.2 and rename the  
really advanced work Mailman 3.0.

I know I've gone back and forth on all this numbering stuff, but if  
we try really really really hard to keep our focus, I think we could  
get out a 2.2 that looks and acts a lot like 2.1 but with a better  
look and feel, as well as reducing a couple of big pain points.

>   Terri (who, uh, maybe, might sorta have some unfinished admin
> documentation that got left alone 'cause it seemed like MM3 had to be
> just around the corner... three years ago. ;)  )

Guilty as charged. :)

Thoughts?
- -Barry

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

iQCVAwUBRj9HsXEjvBPtnXfVAQKHHAP9FHEHpg18wzQk2xXyVOcAKYtS3aDX5//T
/R5bEH4bmUOMcfuMUWXrKAq+EXpH9Hi2idSDByxdKcL7z3ePl5OkVuTpjK7czU9H
EwB/elDX3VRdqQSH1Yvmgxv0tcxwk5pBXbBvzPBeBZJlfCPPBt57lyJXCFbJoSif
UYi1+H3mZ48=
=3vSu
-END PGP SIGNATURE-
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

Re: [Mailman-Developers] Should we move to Bazaar?

[Mads Kiilerich]

Barry Warsaw wrote, On 05/04/2007 03:28 PM:
>> Mr Mercurial might soon come up with an alternative:
>> 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?

I asked them and just got a reply from Matt that "hgserve.org now exists",
http://selenic.com/pipermail/mercurial/2007-May/013105.html - but I 
haven't heard any further details yet.

/Mads
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

Re: [Mailman-Developers] Should we move to Bazaar?

[Stephen J. Turnbull]

[Mike -- I'll get back to you on this, but wanted make sure I pinged
you before I forget ]

Barry Warsaw writes:

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

 > > I'll take svn2hg via Tailor, since that's what I'm using anyway for
 > > XEmacs.
 > 
 > Cool thanks.  I'd love to see what you come up with.

OK, I'm 20% through (~svn rev 1500) and it's after 1am, and tomorrow's
Sunday/family day, so I'm going to jump the gun a bit and hope it does
finish and give me a repo.  Report:

I'm now a lot less happy with Mercurial than I was a day ago.

1.  Mercurial tracks only files directly, and represents directories
in metadata somehow, apparently ad hoc, and buggily.  Operations
it handles fine with files cause exceptions leading to abort with
directories.

2.  This resulted in a situation (at svn rev 745) where the
mailman/cgi directory was removed.  hg proceeded to throw a
mercurial.util.Abort exception when asked to commit the deletion
to the repo, the exception propagated back up to tailor, which
then does abort.

I worked around by trapping that particular case and assuming that
any Abort at that point was due to file not found.

3.  In the process of analyzing and patching, it became apparent that
Mercurial basically just terminates on such unexpected conditions,
because Abort was the only exception I found in use!  (Granted,
this is pretty high-level/ui-oriented stuff, the module is called
commands.py.  In a UI asking the user to try again is not that
unreasonable.)

Worse, the Abort exception takes an error message as an attribute,
but translates it via gettext *at initialization*!  So there's no
way to reliably catch these exceptions, differentiating on the
error message. :-(

4.  Tailor logs the svn log message, but the Mercurial repo's "short
summaries" just cite the svn rev no.  It's possible to get the
whole commit message with "hg log -v", but this basically makes
the short summary useless.  More hacking needed 

Mercurial still seems like a fine dvcs---obviously these problems
don't affect ordinary use.  But it would seem risky to extensible or
embed.

(BTW, it's 1:36 and I'm up to rev 3890, about halfway.  Go, Tailor, go!)

¡Buenas noches!



___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

Re: [Mailman-Developers] Should we move to Bazaar?

[Terri Oda]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 4-May-07, at 7:05 PM, Mark Sapiro wrote:
> I'm just now trying to catch up on this thread. Mostly, I have nothing
> to contribute because I have no experience with any dvcs.
>
> That said, for me personally, I don't mind learning something new.

I, like Mark, have little to say about dvcs (I've only passingly used  
Bazaar) but I'm happy to learn whatever I need to know.

However, I would like to say that I hope this discussion doesn't  
dissuade people from doing that UI work right now.  Please please  
please don't wait on this, 'cause if we wait for the Next Big Thing  
we're going to wind up with no updated UI, once again.  Not that I'm  
a cynic. ;)

  Terri (who, uh, maybe, might sorta have some unfinished admin  
documentation that got left alone 'cause it seemed like MM3 had to be  
just around the corner... three years ago. ;)  )


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

iD8DBQFGPDtxYWvHDqWmQaoRAh7yAKDOgK/6+kTNV9cV/RQJGJAP2XTJTACfWBhJ
qMsOaY8S/RzQ8zgZ2mt0gh4=
=7012
-END PGP SIGNATURE-
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

Re: [Mailman-Developers] Should we move to Bazaar?

[Tokio Kikuchi]

Hi all,

Sorry that I can't say anything nice on this thread but my feelings on 
this distributed somthing :-P is just the same as Mark's.  Currently, I 
am extremely busy on everyday duties and difficult to find time to code. 
  I will be able to spare more time for mailman when the cemester ends 
in July.  I will catch up any change in the version control system then. 
So please feel free to select anything better.

Mark Sapiro wote:
> Barry Warsaw wrote:
>> 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>).
> 
> 
> I'm just now trying to catch up on this thread. Mostly, I have nothing
> to contribute because I have no experience with any dvcs.
> 
> That said, for me personally, I don't mind learning something new. It's
> one of the underlying reasons why I'm here in the first place. And
> while its always nice to have a pain free way to get from A to B, the
> pain can be managed if B is a clear improvement.
> 


-- 
Tokio Kikuchi, [EMAIL PROTECTED]
http://weather.is.kochi-u.ac.jp/
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

Re: [Mailman-Developers] Should we move to Bazaar?

[Stephen J. Turnbull]

Barry Warsaw writes:

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

Why not do both?  That is, if Tailor does its thing well, we can
cheaply have a dvcs mirror auto-synced to the svn 2.1 branch.  If Mark
and Tokio *both* agree, then we can abandon the svn branch.  *Until*
they do agree, people submit patches to the tracker as usual.

I predict they'll get used to the "pull the 'this-patch' branch from
my repo @ URL" style right quick, though.



___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

Re: [Mailman-Developers] Should we move to Bazaar?

[Mark Sapiro]

Barry Warsaw wrote:
>
>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>).


I'm just now trying to catch up on this thread. Mostly, I have nothing
to contribute because I have no experience with any dvcs.

That said, for me personally, I don't mind learning something new. It's
one of the underlying reasons why I'm here in the first place. And
while its always nice to have a pain free way to get from A to B, the
pain can be managed if B is a clear improvement.

-- 
Mark Sapiro <[EMAIL PROTECTED]>   The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan

___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

Re: [Mailman-Developers] Should we move to Bazaar?

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On May 4, 2007, at 3:57 PM, Stephen J. Turnbull wrote:

> That's right.  In my integration workspace maintained under git, I
> basically branch for *every* commit back to the XEmacs CVS, and delete
> the branch when I see the commit notice.  In my sandbox, I have about
> 75 branches.  I branch for reviewing others' patches, I branch for
> typo fixes that can be pushed to mainline immediately.  I switch
> branches when I fix typos while working on larger tasks, then switch
> back and pull the typo.

I do the same thing.  It's really a fundamentally different way to  
think about developing software, IME.  Since CVS we're so conditioned  
to the weight of branches that this is a really liberating  
enlightenment.

> I cannot imagine doing that in CVS or Subversion, nor have I yet seen
> a ViewCVS of an svn repo that looks like that.  But Arch (tla or bzr),
> git, and hg repos all have more branches than a centipede has legs, at
> least for active projects.  It's possible that svk could support that
> style, though, since it is decentralized.
>
> The other question about svn/svk is does it have a rebase operation?
> ("Rebase" is from git; it's called "tla update" in Arch, probably the
> same in bzr, "patch commutation" in Darcs.)  That is, suppose you have
> a revision graph
>
>  A --> B --> C  mainline
>   \
>\-> D --> E  experiment
>
> Can it be transformed to
>
>  A --> B --> C  mainline
>   \
>\-> D --> E  experiment
>
> when you realize that "experiment" is not ready for immediate merge?
> Or to
>
>  A --> B --> Cmainline
> \
>  \-> D --> E  experiment
>
> if you know that E conflicts with C (either textually, or because
> they're different ways to implement the same change)?

I've not needed to do this yet, but I can see where it would be a  
very useful feature to have.  Here's what the www.bazaar-vcs.org  
pages have to say about it.

 From http://bazaar-vcs.org/ShowStoppers/Samba

A rebase plugin would be very nice, with a rebase-push command. It  
should be used in combination with bound branches. The rebase-push  
command should try to rollback local commits, then pull all new  
revisions from the master branch and recommit to the master branch  
one by one. And then pull the new commits back to the local branch.  
Maybe a rebase-pull command would do the same but not directly push  
the local changes, but instead recommit locally. This features seems  
to be related to patch reordering, patch refactoring and a bzr sync- 
trees command. See also http://www.kernel.org/pub/software/scm/git/ 
docs/git-rebase.html. The rebase feature should be only used on  
integration branches with unrelated patches, so that they don't  
appear as one big merge revision in the master branch. For feature  
specific branches normal 'merge --pull' and a final 'push' should be  
used.

> That's really a more important operation to distributed development
> than starmerge (unless you're Linus), because it is the fundamental
> operation for non-core developers producing the occasional patch or
> perhaps a single, long-lived variant (think Richard Barrett's MHonArc
> patch).

I do something similar all the time, but generally what I do is  
branch a local "pristine" branch off the mainline branch, then all my  
dev branches are branches off of pristine.  When I need to pull the  
mainline into a dev branch, I 'bzr pull' the pristine branch to get  
the tip of mainline, then I merge & commit in any dev branch that I  
want to rebase to the tip.  I've not needed to rebase to anything  
other than the tip (though I do occasionally have to resolve  
conflicts of course), but I could imagine that'd be doable by  
manually specifying a revision to branch from.

- -Barry


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

iQCVAwUBRjurhXEjvBPtnXfVAQKpWQP/ctmR9pNJqCj4vRJ9jWNltPVvvBpnpUqf
Sc0FWtGa3KYdgxsGIMmhXtcusfmUOcu7oeoaFsU3GG3npDbDi6p6SOy5XajjWOla
2DMDNwD7FJTZOW4kKx6ghF7YDDdm1LfMJlGJi6NMQX5h0W++WAOTYrqEOy/rXej4
tC8ff0hKLyo=
=Rx3Z
-END PGP SIGNATURE-
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

Re: [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-
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Sear

Re: [Mailman-Developers] Should we move to Bazaar?

[Stephen J. Turnbull]

Barry Warsaw writes:

 > On May 3, 2007, at 11:50 AM, Jon Scott Stevens wrote:

 > > #1. *everyone* knows how to use it and almost all OSS software
 > > projects use it.

You could say the same for Microsoft Windows.  But not for svk.  svk
apparently uses an idiosyncratic notation, not horrible or anything,
but not the same as svn either.

 > > #2. The subversion developers are *awesome*. I used to work with them
 > > at CollabNet and know them personally. Very smart great guys.

And (at least as of 8 months ago) still making no moves in the
direction of implementing lightweight branch and merge operations.

 > > #3. SVK solves the problems that you are talking about.

Does it?  I browsed the svk site trying to find something like Martin
Poole's design notes for bzr or hg's design whitepaper or git(7) or
Darc's Theory of Patches appendix.  Most of the stuff that would be
relevant to the problems Barry describes comes under links that point
to empty or nonexistent pages. :-(

The book apparently has not been worked on since mid-November.
http://svkbook.elixus.org/nightly/en/svk-book.html

If the documentation is any indication, svk cannot be considered
mature.

The article at perl.com is useful overview though:
http://www.perl.com/pub/a/2004/03/03/svk.html.

 > > #4. It would allow you to host your source code on code.google.com
 > > for free and be able to have the benefits of taking advantage of
 > > google's infrastructure.

 > Does svk solve some of svn's problems?
 > 
 > - - The need to use svnmerge or similar tool so that revisions in  
 > different branches don't merge multiple times

svk claims to implement some of the advanced merges pioneered by Tom
Lord in Arch.  That would go a long way (the same algorithms are
implemented in bzr, of course).  However, choice of merge strategy in
Arch is a black art.

 > - - The need to sometimes commit changes before you're ready (i.e.  
 > double moves)
 > - - Inexplicable errors with cryptic error messages
 > - - Inability to merge across renames
 > - - True nested branches (svn:externals is broken).

 > share.  I'm skeptical that svk will substantially improve the  
 > development model over svn, but maybe I'm just guilty of a greener  
 > pastures mentality.

You'd need somebody who uses it heavily to say.  But the home page
talks the talk; it could be equivalent to bzr on that front (up to a
point; the theory on that wiki is all by reference to Tom Lord and
Martin Poole and David Roundy).  Does it walk the walk?

I also don't see a lot about how to use svk in a distributed project.
It seems like the author is normally the only user of his
repositories; he just didn't want to be tied to a central server.
(That's probably not true, but the documentation reads that way.)

And, dare I mention that svk is a Perl application?

 > >> Branches in Bazaar are cheap, unlike in Subversion.
 > >
 > > I'm really sorry Barry, but that's just plain untrue. Read this:
 > >
 > > http://svnbook.red-bean.com/en/1.0/ch04s02.html
 > > "Cheap Copies"
 > 
 > It's not the same thing.  svn cp is pretty heavyweight compared to  
 > bzr branch.  To have an svn branch revision controlled it has to be  
 > committed back to the server and that's what makes it so heavy.  With  
 > bzr (and I'm assuming hg), you can branch locally 'til the cows come  
 > home,

That's right.  In my integration workspace maintained under git, I
basically branch for *every* commit back to the XEmacs CVS, and delete
the branch when I see the commit notice.  In my sandbox, I have about
75 branches.  I branch for reviewing others' patches, I branch for
typo fixes that can be pushed to mainline immediately.  I switch
branches when I fix typos while working on larger tasks, then switch
back and pull the typo.

I cannot imagine doing that in CVS or Subversion, nor have I yet seen
a ViewCVS of an svn repo that looks like that.  But Arch (tla or bzr),
git, and hg repos all have more branches than a centipede has legs, at
least for active projects.  It's possible that svk could support that
style, though, since it is decentralized.

The other question about svn/svk is does it have a rebase operation?
("Rebase" is from git; it's called "tla update" in Arch, probably the
same in bzr, "patch commutation" in Darcs.)  That is, suppose you have
a revision graph

 A --> B --> C  mainline
  \
   \-> D --> E  experiment

Can it be transformed to

 A --> B --> C  mainline
  \
   \-> D --> E  experiment

when you realize that "experiment" is not ready for immediate merge?
Or to 

 A --> B --> Cmainline
\
 \-> D --> E  experiment

if you know that E conflicts with C (either textually, or because
they're different ways to implement the same change)?

That's really a more important operation to distributed development
than starmerge (unless you're Linus), because it is the fundamental
operation for 

Re: [Mailman-Developers] Should we move to Bazaar?

[Stephen J. Turnbull]

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.



___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

Re: [Mailman-Developers] Should we move to Bazaar?

[Stephen J. Turnbull]

Barry Warsaw writes:

 > So my take away from this is that while a conversion would be / 
 > possible/ it's not completely seamless or automatic.  If we choose  
 > wrong, we'll suffer some pain, but we'll recover. ;)  Would you say  
 > that's accurate?  I could live with that.

I really doubt we'd suffer much pain, since current capabilities are
so similar.  But my experience with Tailor is that it's not perfect,
there is some risk depending on the quality of the adapters to the
VCSes in question.

For example, CVS will give you user names for committers, while modern
systems use fullname-email pairs.  You'd like to automatically convert
(this is not rocket science ...), but Tailor currently gives no way to
feed in a dictionary.  I mentioned that git gives you the distinction
between committer and author (if you have Linus's legal problems, you
might care, no?)  That kind of thing.

What you won't have a problem with is commit-is-transaction semantics.
The version graph of the project will be preserved intact.  That
should be good enough.



___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

Re: [Mailman-Developers] Should we move to Bazaar?

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On the Mercurial front, last night I tried to use yasvn2hg to convert  
the Mailman repository to hg.  The conversion failed however:

Error: could not classify changeset 102

I haven't had time to try some of the other conversion scripts.

I'd bet this problem is related to the way SF did the original cvs to  
svn conversion.  'svn log -r102' is unhelpful and 'svn diff -r102'  
produces gobnormous amounts of output (537k lines).  It looks like a  
revision that copied things from the trunk to the Release_2_1-maint  
branch.

To be honest, I haven't tried the bzr conversion, but I know that at  
one point (way before I joined Canonical) it was done successfully.   
The current Launchpad branches are using the old SF urls and are out  
of date, but I'm getting that fixed.

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.

- -Barry

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

iQCVAwUBRjs8+HEjvBPtnXfVAQLkgwQApstdKvV5b26btKiEwWlHFnM9j1IlqTw1
Hg1HZlKl/A8bm6ae4FKk5w4hsu7iJOzZBWT7zWCrBko2jP6RlbUL+ZjMMlCsS+W3
Kq5FtC5Cb+Tg1GHomFTNcOpzTq7gdavFdxXpm108lg9eOzoGPgQaXaIc6BZcf9ej
XB7GxUqhVy0=
=NlBu
-END PGP SIGNATURE-
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

Re: [Mailman-Developers] Should we move to Bazaar?

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On May 3, 2007, at 10:42 PM, Ethan Fremen wrote:

> Barry Warsaw wrote:
>
>> Of course, I think it /will/ make our lives harder in some ways.  As
>> we've seen, folks like cPanel have their own forks that they modify,
>> and then their users come looking to us for support, which we can't
>> give them.  Having more public branches out there will increase our
>> support costs.
>
> I would submit that much of what has caused people in the Mailman
> community to maintain their own forks is because the software  
> design is
> insufficiently open, not so much on account of checkin privileges.

It's both I think, and they're related.  The link is the FSF  
copyright assignment requirement, but that is a can of worms I really  
don't want to open up right now.  My hope is that a dvcs will allow  
us to break that link and let innovation occur independently of the  
legal impositions.

> Moving Mailman development to distributed trees will force, I suspect,
> more modularization and extensibility of the code, which will  
> reduce the
> need for long-lived, independent forks.

Modularization is a very high priority for me in the next release.

> Basically, I suspect that while it might increase support issues in  
> the
> short term, it will ultimately reduce the support-to-participant  
> ratio.

That's my hope too.

- -Barry

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

iQCVAwUBRjs2nnEjvBPtnXfVAQIiUgP9GgqTRLbD/cxYQ/bv/0FLbHxbGFiUBBPw
StxUjn7Yo9smnv2V/ek3eEeB3ygyBNREYE08Jwj488jBIdVerGZmKxOpMxlg4H4i
Q0/HwmnX/n45+zOYGidYgfJdjCeELnC4JUabuqRoI21z1N4kbkX49l5geueJ+Mcs
cAjKbQcPYE0=
=Jr3C
-END PGP SIGNATURE-
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

Re: [Mailman-Developers] Should we move to Bazaar?

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On May 3, 2007, at 9:45 PM, A.M. Kuchling wrote:

> On Thu, May 03, 2007 at 08:50:16AM -0700, Jon Scott Stevens wrote:
>> http://en.wikipedia.org/wiki/SVK
>
> What about SVK's speed, though?
>
> There was discussion of providing a DVCS mirror of the Python SVN, so
> I tried at making a copy of the repository via SVK, and SVK looked
> like it was going to be painfully slow; I calculated something like 13
> hours to create the initial mirror (but I killed it after an hour,  
> so that's an estimate).
>
> Python has about 55,000 revisions, so mirroring is obviously a big
> job, but that seems unusably slow.  Maybe Mailman is small enough to
> take a more reasonable time.

Mailman is currently at revision 8197.

- -Barry

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

iQCVAwUBRjs1hXEjvBPtnXfVAQLmNQQAnT4nozIYUL9bPmNBB/7fb25Cb1UBTiKg
fy8pXFYZRhBegl1Cdg24q+h4d7IZXAzTslTHhaE0J9yPBiKoslovpBX50EMrE8I6
0iYZqjO39O1aAag3nvWTw1QhDCGBH6+4ukjg/XDL2XQIrJwlkNPq+jyJp3tX0mp6
hZcypTuPmAI=
=A0Za
-END PGP SIGNATURE-
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

Re: [Mailman-Developers] Should we move to Bazaar?

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On May 3, 2007, at 2:06 PM, Mads Kiilerich wrote:

> Barry Warsaw wrote, On 05/03/2007 05:16 PM:
>> Alioth is for Debian only, right?  Would they host Mercurial branches
>> for other FLOSS software like Mailman?  If we go with Mercurial,
>> we'll need someone reliable to host the official branches.  I
>> certainly don't want to do that myself!  Is there a Mercurial
>> equivalent to SF for cvs and svn, or Launchpad for bzr?
>>
>
> Mr Mercurial might soon come up with an alternative:
> 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?

- -Barry



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

iQCVAwUBRjs1GnEjvBPtnXfVAQJiQQP/Rh+AAFDT43Mn4+WCjLEhxriXLUASsBoN
es8bJohwd76wqUvL83VL8UedIIxW0g8UdRB7v+NtD/k12bL8F3RPBUZQqw/lhYUb
gYrPT2uNfQ73GDf3VzXPc6YIITEoTKuuSlg8YWY0C6hcvWdTfC78LMX4MclC+NU2
Jz1uz6I1GjU=
=B5Ze
-END PGP SIGNATURE-
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

Re: [Mailman-Developers] Should we move to Bazaar?

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On May 3, 2007, at 12:57 PM, Stephen J. Turnbull wrote:

> Barry Warsaw writes:
>
>> Your point about interoperability is an important one, and definitely
>> a factor in the decision.  I think the risk is mitigated by tools
>> like Tailor,
>
> Tailor is great, but "mitigated" is as far as you can go.  The basic
> stuff like branches and committer id is properly moved from one to the
> other.  However, you can lose some metadata going from one dvcs to
> another if the target doesn't support it.  For example, git supports
> both author and committer IDs for each commit, which others don't, and
> git has its signed tags.

So my take away from this is that while a conversion would be / 
possible/ it's not completely seamless or automatic.  If we choose  
wrong, we'll suffer some pain, but we'll recover. ;)  Would you say  
that's accurate?  I could live with that.

- -Barry

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

iQCVAwUBRjs0x3EjvBPtnXfVAQJ/kAP/SuvnK3sZyiAJSt+xilwWJxF9wOo04Dbw
uzk/e8yEOWg8UoAxSZAUny5c+sIb7QI0PI+AWI7gJuUrhu2HM24nAUT1zztmSHk1
pSpAitzHK15uknyntbtS3opYkZPJe/q8qiraITC4PEfvjOF67KbiImWlz+IgU0Kv
P5m0f8q5UmQ=
=p9+f
-END PGP SIGNATURE-
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

Re: [Mailman-Developers] Should we move to Bazaar?

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On May 3, 2007, at 11:50 AM, Jon Scott Stevens wrote:

> Since I haven't seen anyone else mention this... there is also:
>
> http://en.wikipedia.org/wiki/SVK
>
> I say stick with Subversion/SVK:
>
> #1. *everyone* knows how to use it and almost all OSS software
> projects use it.
> #2. The subversion developers are *awesome*. I used to work with them
> at CollabNet and know them personally. Very smart great guys.
> #3. SVK solves the problems that you are talking about.
> #4. It would allow you to host your source code on code.google.com
> for free and be able to have the benefits of taking advantage of
> google's infrastructure.

Does svk solve some of svn's problems?

- - The need to use svnmerge or similar tool so that revisions in  
different branches don't merge multiple times
- - The need to sometimes commit changes before you're ready (i.e.  
double moves)
- - Inexplicable errors with cryptic error messages
- - Inability to merge across renames
- - True nested branches (svn:externals is broken).

Don't get me wrong, I love svn, and it definitely accomplished its  
mission of being a better cvs.  It's got its quirks and annoyances,  
and we'd be fools to think that the other vcs's don't have their own  
share.  I'm skeptical that svk will substantially improve the  
development model over svn, but maybe I'm just guilty of a greener  
pastures mentality.

>> Branches in Bazaar are cheap, unlike in Subversion.
>
> I'm really sorry Barry, but that's just plain untrue. Read this:
>
> http://svnbook.red-bean.com/en/1.0/ch04s02.html
> "Cheap Copies"

It's not the same thing.  svn cp is pretty heavyweight compared to  
bzr branch.  To have an svn branch revision controlled it has to be  
committed back to the server and that's what makes it so heavy.  With  
bzr (and I'm assuming hg), you can branch locally 'til the cows come  
home, and each branch is fully revision controlled right away, with  
no need to communicate with the parent branch (if say it were on a  
separate server).

- -Barry

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

iQCVAwUBRjsz33EjvBPtnXfVAQLIsQP9GAzWSy4KSOrHMd6WqK/yGgfz3NFqIFRI
mwVwyZdXqKQrnBCKFcENB0IjbQXhnAvSIxxKH/CO1iFCbUkSv5/utJa3ceX6MoXP
NI6wwp/xi427RJ4CXmnW77tRxGGJjAo/MGNKj3ijVs0ksPj83wXZGQrsVS5qg6R2
+7MDlZCNEw8=
=XCOS
-END PGP SIGNATURE-
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

Re: [Mailman-Developers] Should we move to Bazaar?

[Ethan Fremen]

I think it is an excellent idea to move to a distributed source code 
system, and my time in the trenches with Barry doing python.org mail 
stuff makes me think that the easier it is for the lead developers to 
work directly with the support people, the better it is for the software 
project.

I've really appreciated the quality of the hosted wiki solution 
lists.org uses, and directly experienced the difficulty of maintaining a 
host of services on a volunteer basis; system administration is really 
not a great hobby.

So I would land firmly on the side of going with bazaar and frankly all 
the cool kids are on Launchpad already. The fact that Barry can be there 
to apply gentle suasion is a key bonus.

I think any other option would be less ideal if it had less of the human 
component than this option does.

~ethan
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

Re: [Mailman-Developers] Should we move to Bazaar?

[Ethan Fremen]

Barry Warsaw wrote:

> Of course, I think it /will/ make our lives harder in some ways.  As  
> we've seen, folks like cPanel have their own forks that they modify,  
> and then their users come looking to us for support, which we can't  
> give them.  Having more public branches out there will increase our  
> support costs. 

I would submit that much of what has caused people in the Mailman 
community to maintain their own forks is because the software design is 
insufficiently open, not so much on account of checkin privileges.

Moving Mailman development to distributed trees will force, I suspect, 
more modularization and extensibility of the code, which will reduce the 
need for long-lived, independent forks.

Basically, I suspect that while it might increase support issues in the 
short term, it will ultimately reduce the support-to-participant ratio.

~ethan
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

Re: [Mailman-Developers] Should we move to Bazaar?

[A.M. Kuchling]

On Thu, May 03, 2007 at 08:50:16AM -0700, Jon Scott Stevens wrote:
> http://en.wikipedia.org/wiki/SVK

What about SVK's speed, though?  

There was discussion of providing a DVCS mirror of the Python SVN, so
I tried at making a copy of the repository via SVK, and SVK looked
like it was going to be painfully slow; I calculated something like 13
hours to create the initial mirror (but I killed it after an hour, so that's an 
estimate).  

Python has about 55,000 revisions, so mirroring is obviously a big
job, but that seems unusably slow.  Maybe Mailman is small enough to
take a more reasonable time.

--amk
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

Re: [Mailman-Developers] Should we move to Bazaar?

[Mads Kiilerich]

Barry Warsaw wrote, On 05/03/2007 05:16 PM:
> Alioth is for Debian only, right?  Would they host Mercurial branches  
> for other FLOSS software like Mailman?  If we go with Mercurial,  
> we'll need someone reliable to host the official branches.  I  
> certainly don't want to do that myself!  Is there a Mercurial  
> equivalent to SF for cvs and svn, or Launchpad for bzr?
>   

Mr Mercurial might soon come up with an alternative: 
http://marc.info/?l=mercurial&m=117753118122082

and
John Dennis wrote, On 05/03/2007 04:37 PM:
> What is not good for developers is the current fracturing. Projects have
> selected different SCM's requiring developers to become familiar with
> each of them. If one wants to be productive for better or worse there is
> a significant learning curve. I'm already seeing issues where
> cooperating organizations can no longer work together because they no
> longer can manipulate their partner's SCM, or worse have invested
> heavily in tools which only work with a particular SCM (e.g. CVS).
> Eventually this will sort itself out as one or two SCM's generate enough
> gravity to cause convergence. But in the meantime this fracturing is
> producing barriers to productivity.
>   

I think there is a trend in the direction that conversion between SCMs 
can be done trivially on the fly, so that you can use whatever SCM you 
like and still be able to work with upstream whatever SCM they use.

/Mads

___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

Re: [Mailman-Developers] Should we move to Bazaar?

[Stephen J. Turnbull]

Barry Warsaw writes:

 > Your point about interoperability is an important one, and definitely  
 > a factor in the decision.  I think the risk is mitigated by tools  
 > like Tailor,

Tailor is great, but "mitigated" is as far as you can go.  The basic
stuff like branches and committer id is properly moved from one to the
other.  However, you can lose some metadata going from one dvcs to
another if the target doesn't support it.  For example, git supports
both author and committer IDs for each commit, which others don't, and
git has its signed tags.

Dublin Core, anyone?
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

Re: [Mailman-Developers] Should we move to Bazaar?

[Jon Scott Stevens]

Since I haven't seen anyone else mention this... there is also:

http://en.wikipedia.org/wiki/SVK

I say stick with Subversion/SVK:

#1. *everyone* knows how to use it and almost all OSS software  
projects use it.
#2. The subversion developers are *awesome*. I used to work with them  
at CollabNet and know them personally. Very smart great guys.
#3. SVK solves the problems that you are talking about.
#4. It would allow you to host your source code on code.google.com  
for free and be able to have the benefits of taking advantage of  
google's infrastructure.


 > Branches in Bazaar are cheap, unlike in Subversion.

I'm really sorry Barry, but that's just plain untrue. Read this:

http://svnbook.red-bean.com/en/1.0/ch04s02.html
"Cheap Copies"



jon stevens
http://subetha.tigris.org/

___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

Re: [Mailman-Developers] Should we move to Bazaar?

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On May 3, 2007, at 11:42 AM, John Dennis wrote:

> On Thu, 2007-05-03 at 11:16 -0400, Barry Warsaw wrote:
>> Alioth is for Debian only, right?  Would they host Mercurial branches
>> for other FLOSS software like Mailman?  If we go with Mercurial,
>> we'll need someone reliable to host the official branches.  I
>> certainly don't want to do that myself!  Is there a Mercurial
>> equivalent to SF for cvs and svn, or Launchpad for bzr?
>
> The Fedora Project has started project hosting as well. At the  
> moment it
> is Trac based with Mercurial as one of the SCM options.

Cool, thanks for the pointer.

I found this wiki page:

http://fedoraproject.org/wiki/Infrastructure/ProjectHosting?highlight= 
%28hosting%29

Looks like the service is beta-ish, but provides multiple vcs  
support.  We'd probably need to coordinate with the Fedora folks to  
get a project hosted (no auto-registration), but let's keep this one  
in mind.

- -Barry

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

iQCVAwUBRjoFqXEjvBPtnXfVAQLgCAQAl5AAh+FzZ+w69Es/sCLpk6J6zo3d8wU8
LPaJsm7ZWBnPIjXh9KzsnronzLle9Lgut/yLOUjEm5q/TgMzdZ3b1Ndh8FZ67RQE
S/zk2nSiWGIM45rRKn2yjYi2WpceYLvRG+yZOkQXO0mWnxK+3wdkUVNWRMlDryJE
7fNJukgtE5A=
=a6xN
-END PGP SIGNATURE-
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

Re: [Mailman-Developers] Should we move to Bazaar?

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On May 3, 2007, at 11:37 AM, Fil wrote:

>> write privileges are
>> a big sticking point for community participation in code development,
>> to which I agree.  However, he also concluded that dvcs's are /bad/
>> for open source because they encourage private branches, and
>> everything should be done in the open.
>
> My own experience with SPIP (www.spip.net, a project now 7 years old
> and that I "guide") is that there was a lot a frustration when we had
> a 3-devs SVN system. The "big guys" spent time evaluating (and
> rejecting) proposals that were not "good enough".
>
> Two years ago we opened a secondary SVN server, named "spip-zone",
> with a motto of "anything that's free software and relates to SPIP".
> It now has 150+ devs and thousands of projects positively blossom (to
> quote Chairman Mao).
>
> This has been a place where shy developers have been more able to
> express themselves, and now the "core" team has expanded, integrating
> some of these developers. But most surely the "core" is more focused,
> and frustration has almost disappeared.

I think we can do the same thing, without all the pain that svn  
brings with it.  Remember that in bzr (and I'm sure hg is the same),  
branches are /really/ cheap.  In fact, it's encouraged to keep your  
branch changes small, and not worry about branch proliferation.   
Small focussed branches make it easier to review, and merge into the  
main line.

In fact, because you don't need to coordinate with /me/ to create and  
publish branches means anyone can do it.  I envision that the really  
great patches will be easier to merge, and the really great  
developers will be easier to promote.

- -Barry

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

iQCVAwUBRjoEi3EjvBPtnXfVAQKFCAQAgcNkIaot1Hlv+DffA9RlTk5njvb8bOo0
ViELnkoJQxfb4ocBexw6QA09kpDYm3HSYXAN9KUq3BZyH87aMkUSK8Ck1iLGhfye
q4oLOdy0/hEE/AHiAtLxYWwb79Wv7d5DoGkWy+aweiZ4FNtvU02Qcqg5Uqz34hqQ
AJNPefSceFI=
=bj1Z
-END PGP SIGNATURE-
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

Re: [Mailman-Developers] Should we move to Bazaar?

[John Dennis]

On Thu, 2007-05-03 at 11:16 -0400, Barry Warsaw wrote:
> Alioth is for Debian only, right?  Would they host Mercurial branches  
> for other FLOSS software like Mailman?  If we go with Mercurial,  
> we'll need someone reliable to host the official branches.  I  
> certainly don't want to do that myself!  Is there a Mercurial  
> equivalent to SF for cvs and svn, or Launchpad for bzr?

The Fedora Project has started project hosting as well. At the moment it
is Trac based with Mercurial as one of the SCM options.
-- 
John Dennis <[EMAIL PROTECTED]>

___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

Re: [Mailman-Developers] Should we move to Bazaar?

[Fil]

> write privileges are
> a big sticking point for community participation in code development,
> to which I agree.  However, he also concluded that dvcs's are /bad/
> for open source because they encourage private branches, and
> everything should be done in the open.

My own experience with SPIP (www.spip.net, a project now 7 years old
and that I "guide") is that there was a lot a frustration when we had
a 3-devs SVN system. The "big guys" spent time evaluating (and
rejecting) proposals that were not "good enough".

Two years ago we opened a secondary SVN server, named "spip-zone",
with a motto of "anything that's free software and relates to SPIP".
It now has 150+ devs and thousands of projects positively blossom (to
quote Chairman Mao).

This has been a place where shy developers have been more able to
express themselves, and now the "core" team has expanded, integrating
some of these developers. But most surely the "core" is more focused,
and frustration has almost disappeared.

-- Fil
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

Re: [Mailman-Developers] Should we move to Bazaar?

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On May 3, 2007, at 10:37 AM, John Dennis wrote:

> On Thu, 2007-05-03 at 22:01 +0900, Stephen J. Turnbull wrote:
>
> [ superb summary, snipped for brevity ]

Agreed!

I also agree with your assessment John.  It's an evolutionary battle:  
cvs ate rcs, svn ate cvs, and now the next generation is battling for  
dominance.  I think it's too early to pick a winner, the way cvs was  
a clear win for so long, and svn was a no brainer after that.

> If in the decision making process this concern could be taken into
> account I think it would be beneficial. By restricting the options to
> the SCM's which currently have the most mindshare the pain  
> threshold for
> developers would be mitigated and the project would have stronger
> assurances of on-going future support for the SCM.

Your point about interoperability is an important one, and definitely  
a factor in the decision.  I think the risk is mitigated by tools  
like Tailor, and I have confidence that should we choose hg, bzr or  
something else, we'll be able to fairly easily convert if a clear  
winner emerges.

- -Barry

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

iQCVAwUBRjn+4HEjvBPtnXfVAQIQdgP+JpcNOC+a5ZXanIF8NnL91a3mveR2rCu2
yemhPPv7HaJ7FyWKr7W9vAe1cyl7xG6lAsVvlARQNIyFyKxO76NvuZKb8mqUuUUz
7m+PPaJBW1uzTnmPQpxYPmWndZCkAQxjGzWZCNK9IkTg38RyrIIdzgzBqvY1XjAG
ONadNBKUEU8=
=Q/P4
-END PGP SIGNATURE-
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

Re: [Mailman-Developers] Should we move to Bazaar?

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On May 3, 2007, at 9:01 AM, Stephen J. Turnbull wrote:

> Barry Warsaw writes:
>
>> think this is a good time to ask whether we should move from
>> Subversion to Bazaar  for our source code
>> revision control system.
>
> I would rank Bazaar(-ng == bzr) third behind git and Mercurial.  I
> like git because it tastes like Mom's home cooking.

Unless there's a strong constituency behind git, I view it as lower  
on the list than bzr or hg, primarily because of my own sentimental  
bias toward a Python solution.  I like having the ability (and  
desire) to investigate and fix bugs in our vcs if necessary.

Steve says, and I agree, that any of the three would suit our  
purposes.  I think any three would be fast enough, easy enough to  
learn, stable enough, and would solve our current issues, so I don't  
think we can go wrong either way.  BTW, I also think that once we  
move to /any/ dvcs, moving among them will be fairly easy.  E.g. we  
could bring up a Tailor instance if we wanted.  The conversion from  
svn can be a bit painful, but it looks like it'll be doable for  
either hg or bzr.

I don't have much time to investigate all the dvcs's out there, so  
unless someone says "you will not be able to live without feature X  
which only D has!", I'd like to narrow the choice down to either  
Mercurial or Bazaar-ng.

> Mercurial is second because it is likely to be the choice of my main
> project, XEmacs.  It has strong recommendations from people working at
> Sun, where it is already becoming widespread.  Documentation is better
> than git's, and much better for the new user.  It's developed by vcs
> pros.
>
> Bazaar is close to Mercurial, for similar reasons (s/Sun/Canonical/).
> However, I give Mercurial the edge because it is being developed by
> people who develop vcses for their own sake, while Canonical has
> demonstrated that their interest in vcses is instrumental to their
> development business.  Nothing wrong with that per se, but I think
> that dvcses have a long way to go to reach maturity (viz Darcs's
> "theory of patches" approach and its innovative and addictive UI not
> yet copied by any of the other main contenders).  I think it's worth
> going with Mercurial for the possibility of picking up on the "next
> next" generation early.  While the whole point of bzr is to be to tla
> as svn is to cvs. :-)
>
> I should remark that bzr's diffs are currently the best in the
> business.  See my reply to Edward Elhauge and also Bram Cohen's blog
> http://bramcohen.livejournal.com/37690.html.  This advantage probably
> won't last long, though---git and Mercurial both have their diff
> commands well-modularized, it won't be hard to add.

I really appreciate the information Steve.  I've just installed  
Mercurial and I'm going to spend a few days playing with it.

> There are a couple of others out there, but I think the main
> contenders are Bazaar, git, and Mercurial.  IMO any of them will do.

Agreed.

>> One more thing.  If we move to Bazaar, I would host the branches on
>> Launchpad.net, which -- full disclosure again -- is developed,
>> managed, and paid for by my employer.  Why Launchpad?  Because it's
>> convenient, I have insiders I can bug, and because it already
>> supports hosted Bazaar branches.
>
> IMO, this is an important advantage to Bazaar.  Similarly, the Debian
> project sponsors a Mercurial host on Alioth, which I would imagine is
> pretty professionally run.  Barry being an insider at Launchpad is a
> good thing, though.  Does use of Launchpad imply access to the patch
> queue manager, too?  Or is that Canonical-only?  (Not a problem if it
> is Canonical-only, but it's a nice-to-have feature!)

Alioth is for Debian only, right?  Would they host Mercurial branches  
for other FLOSS software like Mailman?  If we go with Mercurial,  
we'll need someone reliable to host the official branches.  I  
certainly don't want to do that myself!  Is there a Mercurial  
equivalent to SF for cvs and svn, or Launchpad for bzr?

I asked around about pqm, but right now Launchpad does not provide  
general pqm services.  I agree it would be very cool to have.

>> Let me emphasis that Canonical is in no way driving this.
>
> Good.  AFAICT, Canonical is a big business, it behaves like a big
> business, but it talks like a charity.  Nothing wrong with the first
> two, but the third confuses me.  I'd recommend keeping arms' length.

There will of course be advantages to using Launchpad and bzr, based  
on my relationship with the company that hosts those.  I will, as  
always, strive to be as open and transparent as possible with the  
Mailman project so that you guys can keep me honest.  IMHO I don't  
think Canonical would want it any other way, but that's speaking as  
an insider.  If ever Y'all ever think decisions are not being made in  
the best interest of Mailman, please speak up!

>> I personally think Bazaar+Launchpad wil

Re: [Mailman-Developers] Should we move to Bazaar?

[John Dennis]

On Thu, 2007-05-03 at 22:01 +0900, Stephen J. Turnbull wrote:

[ superb summary, snipped for brevity ]

Thank you Stephen for your excellent summary, it was very informative
and even handed. I tend to share your view that git and mercurial are
the current best of breed.

At the moment the open source world is boiling with SCM innovation after
nearly 20 years of stability anchored by CVS. This is good.

What is not good for developers is the current fracturing. Projects have
selected different SCM's requiring developers to become familiar with
each of them. If one wants to be productive for better or worse there is
a significant learning curve. I'm already seeing issues where
cooperating organizations can no longer work together because they no
longer can manipulate their partner's SCM, or worse have invested
heavily in tools which only work with a particular SCM (e.g. CVS).
Eventually this will sort itself out as one or two SCM's generate enough
gravity to cause convergence. But in the meantime this fracturing is
producing barriers to productivity.

If in the decision making process this concern could be taken into
account I think it would be beneficial. By restricting the options to
the SCM's which currently have the most mindshare the pain threshold for
developers would be mitigated and the project would have stronger
assurances of on-going future support for the SCM.

-- 
John Dennis <[EMAIL PROTECTED]>

___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

Re: [Mailman-Developers] Should we move to Bazaar?

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On May 2, 2007, at 6:37 PM, John Dennis wrote:

> I'll confess I'm not familiar with Bazaar and what it has to offer, it
> may be the optimal choice, but I'm wondering, have you given Mercurial
> serious consideration?

It was on my radar, but no, I hadn't.  I will though.

- -Barry

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

iQCVAwUBRjnzQ3EjvBPtnXfVAQIkMAP/dJ9F6K528RDmrCCpSj9NdW1etKpRfKPJ
VhdwCldUcB1JW5eQ/hQWeEaoh+r234FGkiC1E9YH7UewQUlZ96+lK4k6LlWOj2uy
G1FqKLct2wIEEoO/Lf4ycP+ItTFdvndVtLNqZHr3biUvpRz+gke0IXyBf2od0ENc
J4bZysB+Kps=
=0oXT
-END PGP SIGNATURE-
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

Re: [Mailman-Developers] Should we move to Bazaar?

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Thanks for all the excellent feedback folks!

On May 2, 2007, at 6:25 PM, Fil wrote:

> when I tried to do some work on Mailman, a while ago (a few years, in
> fact), I was not put off by the (then) CVS system used, but more by
> the fact that it seemed very difficult to get write priviledges (I
> didn't insist enough either, though I got the GNU assignment papers);
> and by the fact that the GNU requirements are quite strict, which lead
> me to wonder what was really "mine" in the patch I would have liked to
> offer (as it was inspired in part by someone else's patch).

I read a blog entry by Ian Bicking about this subject, which I think  
he wrote back in 2005.  He also pointed out that write privileges are  
a big sticking point for community participation in code development,  
to which I agree.  However, he also concluded that dvcs's are /bad/  
for open source because they encourage private branches, and  
everything should be done in the open.

I agree that we should strive for maximal openness, but I don't agree  
that dvcs's necessarily make things less open.  I think it's entirely  
possible they make things /more/ open.  There's certainly nothing  
preventing anyone from publishing their own dvcs branches, perhaps  
even competing with the main line.  While I don't want to encourage  
forks of my own projects, the potential for increased competition  
does keep us honest.  And I think interested ideas that folks like  
you have Fil, can better compete in the marketplace when they are  
just as first class as the main branch.  IOW, having your own  
branches instead of patches means that the successful ones should be  
able to garner more community support, thus improving the likelihood  
that the main line will accept them.  So I think the jury is still  
out on whether dvcs's increase overall openness or decrease it.  I'm  
putting my money on the former.

Of course, I think it /will/ make our lives harder in some ways.  As  
we've seen, folks like cPanel have their own forks that they modify,  
and then their users come looking to us for support, which we can't  
give them.  Having more public branches out there will increase our  
support costs.  We may need to be more careful about blessing the  
official branches and making it clear (on web page footers and such)  
which is being used.

All that being said, the plight that you, Fil, and others go through,  
and the desire on my part to open up the development process more, is  
a big driving factor for me finally getting off my ass and doing  
something about it.  Moving to a dvcs is the first step.

> The ticket system at Sourceforge is/was almost unusable.

That's a side issue, and one I whole-hearted agree with.  Remember  
that Atlassian has provided us with free hosted Jira, which is just  
waiting for us.  The blocker there is that neither I, nor my contact  
at Atlassian, has had time to complete the SF export and Jira  
import.  A case of e-beers and a year's worth of FLOSS karma goes to  
whoever volunteers to help make this happen.

> So, in the end, I have my own little patch on my personal SVN server,
> which of course almost no one has read, and which evidently got
> outdated, and, well, will stay in that state until I find the time to
> upgrade it again, compare all by hand and test.
>
> I'm not sure a new versioning system can help for this kind of
> problem, but if it can, I'm all for it (though I don't really fancy
> learning yet another versioning system, as I'm very happy with SVN for
> my developments).

I don't think there's any controversy that moving to a dvcs will be  
an overall win for all of us.  Certainly learning bzr was pretty  
easy, an hg looks just as easy.  (More on that next.)_

> Not really an answer, and a bit off-topic, sorry. :)  HTH anyway

Cheers,
- -Barry

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

iQCVAwUBRjny4nEjvBPtnXfVAQKV8QQAjnnaA+szCnJaCRmotjELMRVyIzdtpOzi
8grfKrtOgOYhWtIjwwfGyyoT/YsiZtWRs6gOtzh2XMLW2yg0K/f2xg/ibtgcKYUm
NQN27V/xiV4pug9to8mgSb1gtUiV5kWC8+tr0Tra+Hb5hmGKg6iIh974qWt9zmc6
HKADJcCtNEI=
=gFwp
-END PGP SIGNATURE-
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

[Mailman-Developers] Should we move to Bazaar?

[Stephen J. Turnbull]

Barry Warsaw writes:

 > think this is a good time to ask whether we should move from  
 > Subversion to Bazaar  for our source code  
 > revision control system.

I would rank Bazaar(-ng == bzr) third behind git and Mercurial.  I
like git because it tastes like Mom's home cooking.  Er, I mean, the
git model has a strong flavor of Lisp, although "cons", "car", "cdr",
and "get" are about the only operations fully implemented yet.  This
has long been the way I think about vcses, despite long flirtations
with GNU Arch and Darcs.  While Linus is not primarily interested in
vcses, the fact that he chose to implement his personal vcs as a
dialect of the oldest (and still going strong) computer language is
indicative of future possibilities.  If there's going to be another
quantum leap in vcses in the next few years, my bet is that the
prototype will be a child of git.

Mercurial is second because it is likely to be the choice of my main
project, XEmacs.  It has strong recommendations from people working at
Sun, where it is already becoming widespread.  Documentation is better
than git's, and much better for the new user.  It's developed by vcs
pros.

Bazaar is close to Mercurial, for similar reasons (s/Sun/Canonical/).
However, I give Mercurial the edge because it is being developed by
people who develop vcses for their own sake, while Canonical has
demonstrated that their interest in vcses is instrumental to their
development business.  Nothing wrong with that per se, but I think
that dvcses have a long way to go to reach maturity (viz Darcs's
"theory of patches" approach and its innovative and addictive UI not
yet copied by any of the other main contenders).  I think it's worth
going with Mercurial for the possibility of picking up on the "next
next" generation early.  While the whole point of bzr is to be to tla
as svn is to cvs. :-)

I should remark that bzr's diffs are currently the best in the
business.  See my reply to Edward Elhauge and also Bram Cohen's blog
http://bramcohen.livejournal.com/37690.html.  This advantage probably
won't last long, though---git and Mercurial both have their diff
commands well-modularized, it won't be hard to add.

Re some vcses that IMO won't fly:

Darcs, although very interesting as a radical departure from the other
dvcses, is IMO not ready for prime time yet.  Development is somewhat
slowed by being written in Haskell, which makes it hard for most users
to contribute directly.  It also has some really dire performance
problems that show up in ordinary usage for a non-negligible fraction
of projects.

The Arch 1 family (arx, tla, baz) is a non-starter.  It's very usable,
but for future development, it's orphaned.  The main author, Tom Lord,
is once again being a radical innovator, movint on to Arch 2.  But
Arch 2 (also known as "revc") is not ready for "real work" yet, it may
not even be self-hosting at this point.  In any case, Tom is not
currently able to push development very actively.

There are a couple of others out there, but I think the main
contenders are Bazaar, git, and Mercurial.  IMO any of them will do.

 > Bazaar is a distributed version control system.  This is really the  
 > crucial different between centralized systems such as Subversion and  
 > CVS, and it's the main draw for wanting to switch.

It also means that at the present time there's very little difference
between git, Mercurial, and Bazaar in use.  The real difference is in
the goals of the maintainers, namely "keeping Linus happy", "making
the best possible dvcs", and "what we use at work."  All of these have
their advantages.

Everything that Barry wrote that I've cut out I agree with, strongly.

 > One more thing.  If we move to Bazaar, I would host the branches on  
 > Launchpad.net, which -- full disclosure again -- is developed,  
 > managed, and paid for by my employer.  Why Launchpad?  Because it's  
 > convenient, I have insiders I can bug, and because it already  
 > supports hosted Bazaar branches.

IMO, this is an important advantage to Bazaar.  Similarly, the Debian
project sponsors a Mercurial host on Alioth, which I would imagine is
pretty professionally run.  Barry being an insider at Launchpad is a
good thing, though.  Does use of Launchpad imply access to the patch
queue manager, too?  Or is that Canonical-only?  (Not a problem if it
is Canonical-only, but it's a nice-to-have feature!)

 > Let me emphasis that Canonical is in no way driving this.

Good.  AFAICT, Canonical is a big business, it behaves like a big
business, but it talks like a charity.  Nothing wrong with the first
two, but the third confuses me.  I'd recommend keeping arms' length.

 > I personally think Bazaar+Launchpad will make some of our lives
 > easier,

+1 on that.  I've now done merges of multi-megabyte patches with both
Darcs and git.  It's thinkable.  Doing it with CVS or Subversion no
longer is.  (That would apply to bazaar, too, I'm sure, though I have
no experience with 

Re: [Mailman-Developers] Should we move to Bazaar?

[Stephen J. Turnbull]

Edward Elhauge writes:

 > Would you compare Bazaar to GnuArch (tla):
 > http://www.gnuarch.org/arch/
 > 
 > Is your Bazaar a different branch of Arch?

Yes.  The bazaar Barry is talking about is commonly called "bzr" (the
name of the command) or "bazaar-ng".

It's similar in that it is a distributed SCM.  If you like *Arch* as
opposed to the features offered by all the dSCMs (git, Mercurial,
Darcs, ...), you may be distressed by bzr, as internally it's quite
different from Arch.  The repo model is very different, many of Arch's
commands are gone or work differently, etc.  YMMV, of course; it
depends on how much your use cases depend on those aspects of Arch.

The pluses to bzr, compared to larch, ArX, tla, or bazaar (aka baz),
in order of importance to the seasoned tla user:

1.  Fast.  The different repository model allows much faster
transactions, both locally and across the internet.

2.  Everyday workflow (branch, routine merge, commit, new project,
...) is very similar to tla.  But then, it's very similar to git
or darcs, too. :-)

3.  The "best available" diff algorithm for code.  It's marginally
slower than GNU diff or python difflib for very small diffs, but
traditional diffs are O(N^3) while patiencediff use by bzr is
O(N^2).  Furthermore, it is claimed by its author (Bram Cohen, who
you may know better as "Mr. BitTorrent") to give much more
readable output in many cases.  It is plug compatible with other
diffs (ie, can be tuned to give diff -c or diff -u output), so it
seems likely that other projects (Darcs is considering it right
now) will adopt it, at least as an option.  It generally produces
larger diffs, but if you prefer -U 3, you obviously aren't
interested in minimizing diff size. :-)

4.  Better error reporting and warnings.  Not that that's difficult
compared to tla. :-(

___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

Re: [Mailman-Developers] Should we move to Bazaar?

[Edward Elhauge]

Hi Barry,

Would you compare Bazaar to GnuArch (tla):
http://www.gnuarch.org/arch/

Is your Bazaar a different branch of Arch?

I ask because I've used tla a lot and liked it. On the Arch page
they have the main Arch repository as:
http://bazaar.canonical.com/

* Barry Warsaw <[EMAIL PROTECTED]> wrote on [2007-05-02 15:09]:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> I'm very encouraged and excited by all the interest from developers  
> who want to get involved in the Mailman project.  I've always wanted  
> to broaden the sphere of developers beyond the current core three  
> (though I can't say enough about the great job Tokio and Mark do).  I  
> think this is a good time to ask whether we should move from  
> Subversion to Bazaar  for our source code  
> revision control system.
...
---end quoted text---

-- 
Edward Elhauge <[EMAIL PROTECTED]>
"The life which is unexamined is not worth living." -- Plato
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

Re: [Mailman-Developers] Should we move to Bazaar?

[John Dennis]

On Wed, 2007-05-02 at 18:09 -0400, Barry Warsaw wrote:
> I think this is a good time to ask whether we should move from  
> Subversion to Bazaar  for our source code  
> revision control system.

> Bazaar is a distributed version control system.  This is really the  
> crucial different between centralized systems such as Subversion and  
> CVS

I'm all for distributed SCM's, using a distributed SCM is a good move.
Internally here there is a *lot* of interest in switching from CVS to a
distributed SCM. The big question is not whether to switch to a
distributed SCM but which one. Out of the many options two seem to have
bubbled to the top as true contenders, GIT and Mercurial.

Mercurial is also written in Python. It seems to be in wide use, it
seems to stable, and other projects support it as an SCM (e.g. Trac,
another popular Python project). I've used Mercurial now for about 5
months and it has worked well. FWIW we have other projects also using
Mercurial.

I'll confess I'm not familiar with Bazaar and what it has to offer, it
may be the optimal choice, but I'm wondering, have you given Mercurial
serious consideration?
-- 
John Dennis <[EMAIL PROTECTED]>

Learn. Network. Experience open source.
Red Hat Summit San Diego  |  May 9-11, 2007
Learn more: http://www.redhat.com/promo/summit/2007


___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

Re: [Mailman-Developers] Should we move to Bazaar?

[Fil]

Hi Barry,

when I tried to do some work on Mailman, a while ago (a few years, in
fact), I was not put off by the (then) CVS system used, but more by
the fact that it seemed very difficult to get write priviledges (I
didn't insist enough either, though I got the GNU assignment papers);
and by the fact that the GNU requirements are quite strict, which lead
me to wonder what was really "mine" in the patch I would have liked to
offer (as it was inspired in part by someone else's patch).

The ticket system at Sourceforge is/was almost unusable.

So, in the end, I have my own little patch on my personal SVN server,
which of course almost no one has read, and which evidently got
outdated, and, well, will stay in that state until I find the time to
upgrade it again, compare all by hand and test.

I'm not sure a new versioning system can help for this kind of
problem, but if it can, I'm all for it (though I don't really fancy
learning yet another versioning system, as I'm very happy with SVN for
my developments).

Not really an answer, and a bit off-topic, sorry. :)  HTH anyway

-- Fil
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

[Mailman-Developers] Should we move to Bazaar?

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I'm very encouraged and excited by all the interest from developers  
who want to get involved in the Mailman project.  I've always wanted  
to broaden the sphere of developers beyond the current core three  
(though I can't say enough about the great job Tokio and Mark do).  I  
think this is a good time to ask whether we should move from  
Subversion to Bazaar  for our source code  
revision control system.

There are plusses and minuses, and I will not make the decision  
unilaterally (unless you want me to. :).  Certainly, Tokio's and  
Mark's opinions are very important here because they are currently  
doing exceptional work on the 2.1 branch and I don't want to  
jeopardize that!  Let me outline my thinking here and get your feedback.

Bazaar is a distributed version control system.  This is really the  
crucial different between centralized systems such as Subversion and  
CVS, and it's the main draw for wanting to switch.  Using a dvcs such  
as Bazaar really changes the way we as developers work on the code,  
and the way other non-privileged developers can interact with the  
project.  The biggest differences are that you can work completely  
disconnected from the central server, and you need have no special  
permissions to have *and publish* fully revision controlled personal  
branches.

The cons are that it's not as mature as Subversion or CVS, but I have  
confidence that it's pretty stable.  It has not yet reached a 1.0  
release, but I think that's coming soon.  (It's been ported to *nix,  
OS X, and Windows, and it's written in Python if that matters).  It  
does not have all the features of Subversion (e.g. nested branches or  
externals), but it has enough to make it useable for everyday  
development.  It takes some getting used to for existing Subversion  
and CVS users, and the documentation is not as good.  But I think  
people can pick it up fairly quickly and there's a lot of effort  
being put into it.

Full disclosure: my company Canonical is the driving force behind  
Bazaar, and uses it internally for all our development.  It's free  
software though, so no worries on that front.  I would not recommend  
it for the Mailman project though unless I thought it could solve  
some real problems, that it was stable enough to rely on, and that  
Mailman would benefit from using it.  Having insiders to heckle  
helps, but it wouldn't be enough if that's all there was.

What problems does it solve?  Well, I'm /still/ struggling to merge  
in the work I did while on the train to PyCon in Dallas because of  
all the contortions I had to go through to work off-line for a couple  
of days.  Bazaar solves this by allowing me to do everything I need  
to do while completely disconnected, except push my changes to the  
master branch.  I could have committed, branched, merged, reverted,  
etc. all in a completely revision controlled way while off-line, and  
then I could have merged all my changes back to the master branch  
when I got back on-line.

It also solves a problem I have of many live branches.  Branches in  
Bazaar are cheap, unlike in Subversion.  This means I can easily  
create branches for my Elixir experiments, for the move to eggs, for  
playing with 5 different templating engines, etc.  And it's easy to  
merge between these.  I can also have private branches that need  
never see the embarrassing light of day until they are stable enough  
to merge into the main line.

What problems does it solve for you?  Well, if you're a developer  
wanting to contribute to Mailman but we don't know you well enough to  
give you commit privileges, you almost don't care.  You can branch  
from the main branch, and have a fully revision controlled private  
branch at your disposal.  You can do commits, branches, merges, etc.  
on your local branches.  You can even publish them via http, bzr+ssh,  
or sftp.  Why is that cool?  Well, say you created the best damn  
templating patch EVAR and you wanted everyone to see it.  Just  
publish your branch (or create a bundle -- a mailable tarball-like  
unit of your changes) and pass around the URL.  Anyone can then take  
a look at your branch, and the core developers can merge them into  
the mainline if we like them.  It's a great way for new developers to  
earn some street cred with minimal admin overhead.

And if we /don't/ like your changes, you do not have to maintain them  
as a disembodied patch.  You can say "screw the Mailman guys, here's  
my cool fork" and have a fully revision controlled version of your  
own, in a way that's much easier to track with upstream than with  
Subversion or CVS.

One more thing.  If we move to Bazaar, I would host the branches on  
Launchpad.net, which -- full disclosure again -- is developed,  
managed, and paid for by my employer.  Why Launchpad?  Because it's  
convenient, I have insiders I can bug, and because it already  
sup