[erlang-questions] Erlang 10 years of Open Source; it is time for the next step

[Kenneth Lundin]

Hi,

We have on our agenda to open up step by step in a way that we
think is advantageous for our own job and for the Erlang community.
We want to keep the quality on the same or higher level.
We don't want there to be many dialects of Erlang just because we
don't think that
is good for the community.
But it is a matter of prioritizing this over new features and it is
quite hard to motivate that this has higher priority than implementing
new features or improving performance.

See also comments below.

On 3/17/08, Torbjorn Tornkvist <tobbe@REDACTED> wrote:
> Hi,
>
> I just got back from QCon 2008 in London.
> Lots of interesting presentations, and among them
> one by Joe Armstrong about Erlang.
>
> One talk was about the Eclipse team and how they had
> gone from a closed development style to a style where
> all their internal processes was completely open to public(*).
>
> It is now 10 years (I think...) since Erlang became Open Source.
> The last year, the interest in Erlang has exploded and I think
> it is time to take the next step; open up the development of Erlang.

We have plans to make Erlang available in a SVN repository.
The plan is that we continue development in Clearcase , since we see
absolutely no advantage in changing that. We will synchronize to and
from the SVN repository
automatically at regular intervals (probably daily)
The repository will be available for anyone with read access..
We will be very restrictive with letting in persons as "committers"
>
> 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.

Clearcase is not a problem.
>
> So, suggestions:
>
> - Put Erlang into a modern (distributed) VCS like Mercurial or Git.
I think we should use a widely used VCS , SVN is widely used and probably good
enough for this.
> - Make it possible to browse the full repository.
The whole point with this is that the source should be browsable.

A completely different thing is letting others than us commit to the repository.
This will be very restrictive in order to keep the stability of the product.

It is worth noting that so far 99% of the patches contributed to
erlang-bugs or erlang-patches need to be corrected or rewritten by us
before they make it into a release. And this has nothing with lack of
VCS to do. The reasons are more of the type:
- solution is not done the way we like to have it
- does not work on all platforms
- buggy
- unacceptable dependencies
- unacceptable incompatibility



> - Open up the bug-tracker to become fully public.
This is a different thing not tightly connected to the VCS issue above.
This would involve a lot of work for us and to what benefit?
It would require us to change bug-tracking system or to use 2 different ones
at the same time.
There is 2 sides of this.
1) The Open source user submitting a bug-report and tracking
bug-reports from other users.
2) Our reception of bug-reports, answering etc. From this point of view it is no
big difference for us in continuing as now with bugreports via
erlang-bugs and erlang-questions. There is nothing wrong with 1) but
for us it probably costs more than it tastes.


> - Publish the testserver result, e.g using CruiseControl.
Why?
All tests should be successful before we release anything.
> - Make the whole testsuite available for download and deployment.
We will probably release some of the test suites step by step.

> - Open up any other (as of today) internal dev.tools, wikis etc.
Why?
What do you think you are missing today?
>
> 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.

See above about the need to rewrite 99% of the patches. Of course the
patches can be better if there are test-suites available, but I don't
expect that most contributors will be able to test and build on 10 to
20  different OS+CPU combinations.
The number of committers must therefore be very restricted. And it
must be possible to restrict commit to specific branches and subtrees
of the code.

A comparision with Eclipse gives:

Eclipse is run as a foundation supported by it's members, I understand is as
this foundation have both people and machinery to run web-sites,
repositories etc.

We could have a foundation for Erlang as well but we are not there
yet. Currently
it is the Erlang group at Ericsson that has to finance this. The
business case for that is not obvious for everyone within Ericsson.

In Eclipse there are a lot of rules and checklists before you can
commit something. I think all these would be relevant for Erlang as
well.

See http://www.eclipse.org/projects/dev_process/index-quick.php
>
> Cheers, Tobbe
>
> (*) www.jazz.net
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions
>

In summary , we are as said not negative to opening up more.
But there must be a business case for everything we do.
It is not always enough with the motivation, "What's good for Erlang
is good for Ericsson". Even if I mostly agree to tha myself.

/Kenneth Erlang/OTP team Ericsson