[erlang-questions] Fwd: Erlang 10 years of Open Source; it is time for the next step
Mon Mar 17 15:21:39 CET 2008
Oops, had intended to send this to the whole list.
---------- Forwarded message ----------
From: Elliot Murphy <elliot.murphy@REDACTED>
Date: Mon, Mar 17, 2008 at 9:44 AM
Subject: Re: [erlang-questions] Erlang 10 years of Open Source; it is
time for the next step
To: Torbjorn Tornkvist <tobbe@REDACTED>
On Mon, Mar 17, 2008 at 6:38 AM, Torbjorn Tornkvist
> Now, I know that Erlang is buried in Clearcase somewhere in the
> dungeons of Ericsson and that it probably will be a major undertaking
> to change the "corporate policy". I think however that the matter
> is worth discussing.
Corporate policy or not, changing version control systems is a lot of work,
and should not be underestimated. I've helped several large companies
version control system, and I'm happy that I can say it is a
reasonable thing to do.
Much of the work can be done up front by a handful of people - the most
important thing to get right is selecting a tool and doing the history
> So, suggestions:
> - Put Erlang into a modern (distributed) VCS like Mercurial or Git.
> - Make it possible to browse the full repository.
I've recently imported the source tarballs into Bazaar, which is an
adaptive/distributed version control system that we use at Canonical:
I was working from the source drops, without access to ClearCase, so
the history is naturally limited to seeing the changes between releases. Still,
it's a good step in the right direction. I am currently working with other
companies to convert major projects from proprietary VCS to Bazaar, while
preserving all their important history, and I'd be delighted to do the same
for the Erlang project.
> - Open up the bug-tracker to become fully public.
> - Publish the testserver result, e.g using CruiseControl.
> - Make the whole testsuite available for download and deployment.
> - Open up any other (as of today) internal dev.tools, wikis etc.
> This way, it would be easy for the public to provide well tested
> patches that easily can be tracked. It would make it easier both
> for the OTP team to cherry-pick patches as well as make it easier
> to maintain non-accepted patches in ones own respositories.
I think that is a great idea. My day job is working on https://launchpad.net
(click on the tour button for more info),
which is a web based development/collaboration suite with mailing lists,
code hosting, distributed bug tracker, support tools, I18N tools, and much
much more. One of the core ideas behind Launchpad is to deal with
dependencies in software - you get a lot of those when building a linux
distribution for example. The place where the bug is reported is not
the place where it needs to be fixed.
The other place where we have seen the ideas we've built in Launchpad work
really really well is in communities based on a programming language - we've
seen significant numbers of python projects moving to Launchpad, for example.
All this rambling is to say that I think this is a great idea, and we at
Launchpad would be happy to provide as much support for the Erlang project
as the community would like. Two recent projects that moved are Zope and
Inkscape. I was really happy to see how the community reacted to the Inkscape
One of the tricky bits with opening up a bug tracker is that sometimes you
have gotten customer information mixed into the bug tracker that absolutely
needs to be kept private, while the majority of the bugs are actually about
technical bugs and could easily be available to the public. We've dealt with
that in Launchpad by building a private bug capability, so if something like
migrating the bugs from the internal tracker to a public bug tracker
was desired we could flag bugs as private as needed.
More information about the erlang-questions