Why Launchpad for Mailman?
Over the last 18 months, I’ve moved GNU Mailman development from SourceForge to Launchpad. The reasons are varied.
Mailman was one of the first projects hosted on SourceForge ages ago. I think our project id is a pride-inducing low 103, and we were even highlighted as its Project of the Month at one point. Of course SF itself uses Mailman to serve its own mailing lists. While the SF guys have always been great (including providing assistance during the migration to LP), I just became increasingly roadblocked by it.
The first major motivation for moving was Bazaar. This is of course the GPL’d distributed version control system developed by Canonical and used for code hosting on Launchpad. Having come from decades of SCCS/RCS/CVS/SVN use, distributed version control systems in general and Bazaar in particular have been an enlightenment on the order of learning Python. I mean, who’d have thunk a version control system could be fun?
After we moved code hosting to Bazaar on LP, evaluating the other benefits of Launchpad became easier. Truth be told, there was (and still is) some resistance in the community to moving to LP because Mailman is a GNU project but LP is not open source. That’s being fixed. The next service to migrate was the tracker, and thanks to the excellent assistance of my colleague Graham Binns, we were able to migrate the SF issues to LP. For years, even before I joined Canonical, I let the Mailman tracker languish because I found it so difficult to use. The simplicity and power of Launchpad’s tracker really shines for me here, especially with its ability to link across projects and artifacts (e.g. branches linked to bugs).
The next major service to consider is translations. While being one of the first Python applicatons to be internationalized and translated, we really have a pretty crufty process for updating translations. Some language champions have commit privileges, but others have to email or upload po-file diffs, or even entire po-files. This really sucks for a number of reasons, probably most of which is that the code developers are too tightly coupled with the translators. Our releases are held up for quite a while as we gather updates to more than two dozen languages.
Currently Mailman has an experimental Pootle service. Despite the gallant efforts of its maintainer, I don’t think it’s working out too well, mostly because it’s not well known and not well integrated with the rest of Mailman’s processes. Again, here’s where Launchpad integration would really shine for us, but until Launchpad is open sourced we won’t be moving translations here.
February 20th, 2009 at 8:26 pm
Correction, only some portions of launchpad are being opened. Some important bits of launchpad are not going to be opened. By delibrate omission of those critical compoments, it will be impossible to reconstitute launchpad as a new service outside of Canonical’s control without significantly re-engineering the non-open pieces. There are no plans on record to ever open the Soyuz or the Codehosting component. These components are being delibrately kept closed in order to protect Canonical’s business model and to make it harder for anyone else to build a hosting service from the lp codebase which competes with Canonical’s business.
Now the Soyuz component may or may not be critical for you as an upstream project, as its deeply tied to the building of Ubuntu. As a GNU project, mailman may never really care about that.
But there is also the Codehosting component. The Codehosting component of launchpad will not be opened. Do you know what that component does? Do you know how it interacts with the other components that are being opened? How critical that is to the launchpad hosting service experience that you are moving your GNU project to? I think it would be wise for you to understand exactly how critical that component is to the LP services you are going to be making use of before you let yourself believe that Launchpad will be ever be open enough to assuage the existing concerns in the GNU community.
-jef
February 20th, 2009 at 8:32 pm
Jef,
Try re-making the whole current sf.net as it is and then complain about Launchpad.
February 20th, 2009 at 8:34 pm
Nevermind that I see zero point in replicating a Launchpad. At best, it will be a barrier for other people to use it – yet another login, no translation pool, no interaction between the two.
Contributing fixes to the current one, sure.
February 20th, 2009 at 8:38 pm
Barry, not to astroturf here (disclaimer: Barry and I both work for Canonical), but how long ago did Mailman switch to Bazaar-on-Launchpad, and how was that transition? There was never a stage when it was just Bazaar without Launchpad, right?
The Pootle was down when I tried it, by the way: “Service Temporarily Unavailable. The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.” 🙁
February 20th, 2009 at 8:47 pm
Flag day was June 22, 2007. http://wiki.list.org/display/DEV/2007/06/22/Bye+bye+Subversion%2C+Hello+Bazaar?showComments=true#comments
It was an unbelievably smooth transition. You’re right though, there was never a time that there were publicly available branches in Bazaar but not on Launchpad.
As for the Pootle server, yeah, that’s a problem ;).
February 20th, 2009 at 9:54 pm
Vadim you are absolutely right. There’s no point in replicating launchpad, as long as Canonical is around to run the infrastructure. And yet that one of Canonical’s stated concerns for keeping Codehosting and Soyuz closed when the other components are being opened. They are on record of being somewhat afraid that other people will take the whole codebase and replicate the service. That is exactly what Canonical wants to avoid. It’s not my rationale..its part of Canonical’s stated rationale for keeping those components closed. If its a bogus fear like you believe, then it calls into question Canonical’s judgement that these things need to stay closed to protect their business interests at the expense of excluding contribution.
GNU forked SF’s codebase awhile ago(back with SF had an open codebase) over this very same issue of openness and created savannah.
Mailman is even listed there as a project.
http://savannah.gnu.org/projects/mailman
It is absolutely consistent with the history of the GNU community to be dismayed at moving GNU projects to Launchpad. In fact Savannah offers bzr as a service. LP is not the only bzr game in town.
http://bzr.savannah.gnu.org/r/
You can either agree or disagree with the GNU community’s hardline stance..that’s your call. And Barry as a main developer can choose where he wants to put mailman…that’s his call.
But its not appropriate to mislead those GNU community members who care about the closed nature of LP into thinking that LP is actually going to be fully opened. Its not. Is Codehosting an important component that hosted projects rely on as part of the integrated LP services? If it is, then using that service for any GNU project will run counter to the long long history of GNU’s principled stance on openness.
-jef
February 21st, 2009 at 1:10 am
Unless I’m missing something, I believe that SourceForge does not even have any plans to open its source code. And this despite being the leading open source development web site. So what’s this Jef complaining about Launchpad not being open enough?