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

Tue Mar 18 17:37:11 CET 2008

Kenneth Lundin wrote:

Thanx Kenneth, a great reply!

Just to make thing clear: my intention has never been to
suggest that Erlang should open up for public commit rights.

See comment below:

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

This is excellent news!

However, it is really beneficial to be able to clone a repository.
This way anyone can publish their patches which then can be merged
by anyone with a maintained history.

> 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

This is just as it should.

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

For me it would be fantastic if I could see, and search, among the
bug-reports. To be able to see the status, and any planned actions.

We have been maintaining our own version of Erlang/OTP ever since
it became Open Source. I know of at least 3 non-Ericsson companies
in Stockholm that do this. It has always been a hassle: to check if
our fixes has been included in the latest release and if not, to
port them into the new code base. This is also connected with the
next paragraph below.

> 
> 
>> - Publish the testserver result, e.g using CruiseControl.
> Why?

Because if it was possible to track all the commits you do,
and have them verified by the test suites (e.g eccessible via
CruiseControl). It would be much easier for us to introduce,
maintain and discard our own patches. Perhaps, we even could
come up with alternative solutions when testcases break...

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

Well, I think that if there is just one focal point
where all the development and supporting processes take
place the easier should it be for everyone. I mean how
much confidential info do you have hidden that touches
your Erlang development processes ? I can't think of
anything... (ok, I left Ericsson 10 years ago :-)
Not having to think about what can be exposed must
make life easer for you, or ?

--Tobbe

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