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

[Christian S]

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

These conclusions here sound quite alien to me.

Open source is a meritocracy. It is free for all to participate and
prove their merit.

It is the product that matters.

When R12-B0 didn't prove good enough, then many deployments stayed
with/at/on[1] their R11 releases waiting for a better release.


In the list, I often see promises that detected issues/bugs will be
fixed in the next OTP release.

Often there is an early fix attached as a patch to the mail. Not a bad
thing. Not at all. Very good indeed.

But the patch is nothing else than an informal branch of the OTP
source tree.  With a suitable DSCM it can be handled within source
control management.

The branch can be given a name. Additional work can be done on it,
version controlled.  It can be merged with some third-party branch
that makes Erlang work on a new processor architecture equipped with
flux-capacitors. Or macs. Or just local patches / other public
pre-release fixes.

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'm afraid that's it's not so straightforward as it sound.
>
>  I do think it is straightforward - if you don't tell people what you
>  expect (in terms of the quality of code contributions and patches) you
>  can't expect much from them.  Simply laying out the expectations would
>  go a long way toward improving the quality of code contributions that
>  the Erlang teams gets from the outside.

To learn from other projects:

What documentation does linux have about expected code quality besides
the hint to read and burn the gnu code conventions?

Isn't it about publishing your patches to the mailinglist and rework
them until you stop getting witty remarks of how your brain is more
like a "." than an "O" ?  (Or stop being handed lollipops :)

Would it be good if good documentation existed so someone new to the
otp source tree and conventions could write a great patch. Yes indeed.
    Has this ever happened for any sufficiently interesting project?

My two öre:  The best documentation for what makes a patch good is a
history of previous good patches and their evolution from unacceptable
to acceptable.  At least it works to do it this way.

[1]
I'm drunk and english prepositions have very vague rules.
This is much more important to fix than any issues people find that
erlang have with punctuation!