-----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 <http://www.bazaar-vcs.org> 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
supports hosted Bazaar branches.
Let me emphasis that Canonical is in no way driving this. They don't
care what we do for Mailman, and understand fully that stuff like
this are community decisions. I personally think Bazaar+Launchpad
will make some of our lives easier, but if you guys do not agree,
we'll stick with what we've got, no harm, no foul.
Please do share your opinions freely here in public, or via private
email.
Cheers,
- -Barry
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin)
iQCVAwUBRjkMDHEjvBPtnXfVAQLcXgP/fnriiMwu9gAQEvXmUiGLXLSfkcmkzyAm cqbu2QjmTm7uZapFq3WLmItfBuoVP3HkOdaa+ibpgR8WJUxt6UksbFXCSPPxmWlR tPI8BS65r0gnf0MUM3dvbvkhizGVmYkhK7gAW6dmH43Um1o5CbskkbaWjIMLJ+0L ter/gGwLu+8= =ftG9 -----END PGP SIGNATURE-----
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
-----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-----
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
-----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-----
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
-----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-----
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 <barry@python.org> 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 <http://www.bazaar-vcs.org> for our source code
revision control system. ... ---end quoted text---
-- Edward Elhauge <ee@uncanny.net> "The life which is unexamined is not worth living." -- Plato
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:
Fast. The different repository model allows much faster transactions, both locally and across the internet.
Everyday workflow (branch, routine merge, commit, new project, ...) is very similar to tla. But then, it's very similar to git or darcs, too. :-)
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. :-)
Better error reporting and warnings. Not that that's difficult compared to tla. :-(
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 <http://www.bazaar-vcs.org> 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 <jdennis@redhat.com>
Learn. Network. Experience open source. Red Hat Summit San Diego | May 9-11, 2007 Learn more: http://www.redhat.com/promo/summit/2007
-----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-----
Barry Warsaw writes:
think this is a good time to ask whether we should move from
Subversion to Bazaar <http://www.bazaar-vcs.org> 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 it.)
One caveat: as the dvcs proponents are always pointing out, it's not necessary to actually use them in a distributed fashion. In fact it's *easy* to just drop them in to the same old workflow. This gives a perceptible improvement for insiders, but in open source you can get lot more! I hope, Barry, that you will allocate some time to reorganizing the Mailman workflow to encourage participation from third parties (eg, Fil, the MHonArc patch, etc).
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 <jdennis@redhat.com>
-----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-----
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?
-----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-----
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.
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/
On Thu, May 03, 2007 at 08:50:16AM -0700, Jon Scott Stevens wrote:
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
-----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:
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-----
-----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 use svnmerge or similar tool so that revisions in
- The need to sometimes commit changes before you're ready (i.e.
double moves)
- The need to sometimes commit changes before you're ready (i.e.
- 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-----
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?<wink>
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 experimentCan it be transformed to
A --> B --> C mainline
\
\-> D --> E experimentwhen you realize that "experiment" is not ready for immediate merge? Or to
A --> B --> C mainline
\
\-> D --> E experimentif 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 non-core developers producing the occasional patch or perhaps a single, long-lived variant (think Richard Barrett's MHonArc patch).
To be honest, since I don't know svk, I can't deprecate it as an app. I don't see any indication that it's an improvement over bzr or hg. OTOH, the documentation is poor compared to bzr or hg. Bottom line: if you can find a champion for it, who will go the distance to support Mailman using it, it might be a choice worth considering. But without a champion, no need to go out of your way IMO.
-----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 experimentCan it be transformed to
A --> B --> C mainline \ \-> D --> E experimentwhen you realize that "experiment" is not ready for immediate merge? Or to
A --> B --> C mainline \ \-> D --> E experimentif 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-----
-----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-----
-----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-----
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 <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
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, tkikuchi@is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/
-----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-----
-----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-----
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
-----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-----
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.<grin>
[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.
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.
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.
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. :-(
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!
-----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-----
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.<wink> 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.
-----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-----
Just a quick update on the conversion to Mercurial.
There are a couple of things you can do right now to play with hg.
I have temporarily made two branches available. See
http://c64.knis.dk:8000/
To check out the Release_2_1-maint branch, do the following:
cd someplace mkdir hg-Release_2_1-maint cd hg-Release_2_1-maint hg init . hg pull http://c64.knis.dk:8000/Release_2_1-maint-conv-1/ hg up
Or alternatively:
hg clone http://c64.knis.dk:8000/trunk-conv-1/ hg-trunk
The conversions has been done from a dead copy of the svn depot; upstream changes will not be mirrored.
The conversions has been made with hgsvn, which gives some of the same functionality as bzr-svn.
Please play with these repositories and let us know what you think. If/when there is enough interest the branches can be set up to be more convenient.
/Mads - who thinks that hg and bzr are so different that hg should have an announcement too, but so similar that they should have similar announcements ;-)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On May 9, 2007, at 7:36 PM, Mads Kiilerich wrote:
/Mads - who thinks that hg and bzr are so different that hg should
have an announcement too, but so similar that they should have
similar announcements ;-)
Thanks for making this available Mads! Can you leave it up for a
little while?
- -Barry
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin)
iQCVAwUBRkJ+YnEjvBPtnXfVAQLNcQP/WTEapnB2F3IBnVeeql8Yt3oCMCAe3DO6 ar9HVk5hVV/qhpEyqUCoGCbrnv9G7rx14Xu/m5iaE3fC6JIou/SoOkzPVWeuXpMQ IOMh/gf9xNepVBEhySQNXJIvfknCqwu4xflAfKAcMI0Vr8I0RotWBfO67KNFzfXs Zat336fYC8k= =//cS -----END PGP SIGNATURE-----
-----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 <http://www.bazaar-vcs.org> 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 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 it.)
I agree about cvs and svn. Wanna compare scars? :)
One caveat: as the dvcs proponents are always pointing out, it's not necessary to actually use them in a distributed fashion. In fact it's *easy* to just drop them in to the same old workflow. This gives a perceptible improvement for insiders, but in open source you can get lot more! I hope, Barry, that you will allocate some time to reorganizing the Mailman workflow to encourage participation from third parties (eg, Fil, the MHonArc patch, etc).
Absolutely. The Mailman developer community must grow and the
development process must become more open. Moving to a dvcs is the
first step, but an important one. There are other things we can do
to encourage participation as well.
- -Barry
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin)
iQCVAwUBRjn86nEjvBPtnXfVAQIajQP+MsY23H78RWkFFpQmJoS6q7IcKnrc1abp ZunpiXy+1ClW35MUMooIOTsZ0p1H473rP6EISUDYzgKgvTqc3oQ1fifEZgXeUE48 L8gsbhUis4aCWXvcmROx6BY5tZ2A7FeLj+gWLTNYOT4nCDaJSUFi1bWiLIj3PTkH 8amYEL87p+o= =9mEU -----END PGP SIGNATURE-----
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 <jdennis@redhat.com>
-----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-----
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
-----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-----
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
-----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-----
Hi,
On Thu, May 03, 2007 at 11:16:57AM -0400, Barry Warsaw wrote: <snip>
Alioth
See http://wiki.debian.org/Alioth and https://alioth.debian.org/projects/siteadmin/ for information about this service.
is for Debian only, right?
"Any free software project where a Debian Developer is involved is fine."
Would they host Mercurial branches for other FLOSS software like Mailman?
"The hg.debian.org admins will create a directory named /srv/hg.debian.org/hg/project-name owned by your project group which will be accessible by hg ssh or http for read-only access. Within that directory, you can hg init/clone/whatever as many branches/repos as you like."
Of course, other hosting offerings might be more suitable.
Bye,
Joost
-- Joost van Baal http://abramowitz.uvt.nl/ Tilburg University j.e.vanbaal@uvt.nl The Netherlands
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On May 4, 2007, at 8:02 AM, Joost van Baal wrote:
Hi,
On Thu, May 03, 2007 at 11:16:57AM -0400, Barry Warsaw wrote: <snip>
Alioth
See http://wiki.debian.org/Alioth and https://alioth.debian.org/projects/siteadmin/ for information about
this service.is for Debian only, right?
"Any free software project where a Debian Developer is involved is
fine."Would they host Mercurial branches for other FLOSS software like
Mailman?"The hg.debian.org admins will create a directory named /srv/hg.debian.org/hg/project-name owned by your project group which will be accessible by hg ssh or http for read-only access. Within that directory, you can hg init/clone/whatever as many branches/repos as you like."
Of course, other hosting offerings might be more suitable.
Thanks for the info Joost. We're really pretty independent of
Debian, though I think they'd probably give us branch hosting if we
asked. It's an option.
- -Barry
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin)
iQCVAwUBRjs393EjvBPtnXfVAQJS+gQAnE+31h9OsNM9HpWekFvwmoUME2/7Iv7E vLaFa5EBOvVcOR32Yy6a8hCSYM25oc2PXXP7VwPCalQXixfmTKiX5/5ThgKrXEfY VwD8NIeD03tplhebRzdGsqoJ4FvAZ0w+NAd8DEjOPIhMneY5OQp0DzamjxbNk+Qi HZYo2Gg9PxE= =K+rf -----END PGP SIGNATURE-----
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
participants (14)
-
A.M. Kuchling -
Barry Warsaw -
Edward Elhauge -
Ethan Fremen -
Fil -
John Dennis -
Jon Scott Stevens -
Joost van Baal -
Mads Kiilerich -
Mark Sapiro -
Stephen J. Turnbull -
Stephen J. Turnbull -
Terri Oda -
Tokio Kikuchi