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

[Masklinn]

On 21 Mar 2008, at 01:45 , Christian S wrote:

>>> I think that the
>>> Erlang people has an 850 tons gorilla code base to take care of,  
>>> eventually
>>> running on different hardware and software architectures. It's  
>>> difficult to
>>> imagine that anybody has the will/stamina/resources to do the same  
>>> in a
>>> reasonable time frame without a strong commitment (read: customer  
>>> driven).
>>> The only case in which opening everything to everybody would make  
>>> sense is
>>> if/when Ericsson give up in supporting Erlang, and given the  
>>> premises that's
>>> unlikely to happen real soon.
>>
>> I completely agree with this.  I don't think anyone (I hope) is
>> suggesting that Erlang development be turned into a democratic free
>> for all.  You absolutely need extremely good, devoted people (like  
>> the
>> Erlang team) steering the project and making firm decisions about  
>> what
>> gets in and what does not.  But, that doesn't mean the development
>> process can not be made more open and transparent and still maintain
>> the full integrity of the project and Ericsson's commercial  
>> interests.
>
> As to submitted patches, overworked OTP members can comment with
> suggestions to what is required for them to swallow a patch whole for
> OTP inclusion if they dont have time to work it right now.
> Version controlled work can progress outside of the OTP team, but the
> work can be committed back.    Using the same tools the whole time.

I completely agree with this: the core Erlang/OTP team should *not*  
have to rewrite "99%" of the patches (Kenneth's number). They should  
not, in fact, have to rewrite any patch (unless the rewrite or  
corrections are trivial, or the patch submitter doesn't have the  
necessary resources e.g. to test the patch on all erlang-supported  
archs): it wastes their time that could be better spent, and it  
prevents contributors from learning what is good Erlang/OTP style/patch.

In the problems Kenneth listed, 4 ought to be handled by the patch  
submitter through feedback by the core team until acceptance of the  
patch:

* "Solution is not done the way we like to have it", a better/more  
acceptable approach should be suggested, and the submitter (or someone  
else) could then go on and rewrite the patch according to this. Would  
also teach contributors and would-be contributors the preferred coding  
style/approaches.
* "buggy", if the patch doesn't work then Erlang/OTP core has no  
reason to accept it
* "unacceptable dependencies", should be listed and the submitter  
could go back to the drawing board, remove them and resubmit the  
patch, which would also send hints to contributors and would-be  
contributors about acceptable and unacceptable dependencies
* "unacceptable incompatibility", should likewise be listed/stated and  
the submitter could then go work on debugging his patch.

That's usually the way it's done on e.g. the Mercurial list, and DVCS  
have a very good support for that kind of workflows.