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

Massimo Cesaro massimo.cesaro@REDACTED
Tue Mar 18 09:21:07 CET 2008


On Mon, Mar 17, 2008 at 5:46 PM, Masklinn <masklinn@REDACTED> wrote:

>
> On 17 Mar 2008, at 16:39 , Massimo Cesaro wrote:
>
> Having a full history, allowing people out of Ericsson to create
> patches (that could then be forwarded to the core team for inclusion)
> or to create temporary or permanent forks to test out features (that
> would probably be much rarer and harder).


Exactly my point. There's no clear advantage in doing this.

>
> The first suggestion is one that is extremely well supported by DVCS:
> any user can clone the repository (which is the equivalent of checking
> it out in e.g. Subversion), then hack around (patch bugs, try to find
> things to cleanup, or even just create documentation patches which are
> already invaluable), save everything in his local repository and when
> needed "patchbomb" an erlang dev list (basically send revision as
> inline patches) so that they can be reviewed and considered for
> inclusion.
>
> The patchbomb step could be replaced by "attach patches to bugs" if a
> bug tracker is opened (the former is the way Mercurial development
> works, the latter is the way Django's works -- in the Python world)
>

Ok, but I was not questioning about the tools used to allow external
development. My concerns are on the opportunity on changing the maintining
mode.

>
> Conceptual integrity would be preserved because only the people who
> already have commit rights now would still have it, and these people
> would therefore have veto power over patches and suggestions, being
> able to enforce design decisions or style issues (and possibly ignore
> patches altogether if they don't have the time).
>
> DVCS would just make contributions easier by allowing everybody to
> hack around locally (with history) and have an history of the Erlang
> development for documentation as well as bug-finding (bisection
> search) purposes.
>

Indeed, but still a supervision from the core development team is required.
Just like today: my experience with this mailing list is that if somebody
has a really useful patch to submit either for the code or for the docs,
he/she just inform of the availability of the patch to the fine people at
Ericsson thourgh the list. I bet that after a close inspection, valuing the
pro and cons of the patch, they'll schedule it for an upcoming release. I
don't see how automating a small part of this process can simplify the life
of a developer.
If I remember well, I know of a user contributed patch solving a real
problem; this was acknowledge by the Erlang team, but was rewritten because
it contained bugs/constraints/whatever that would impact on existing code.
They'll find problems because is their job to run regression testing among
the other tests.
My personal experience with "truly" open source project is that the part
time maintainer has no time/equipment to test it all, so first he just
release the stuff, and then lets the bazaar to sort it out.

>
> >
> > The language and its libraries are not static, they are maintained by
> > Ericsson in a win-win situation for the end user. Until now, the
> > Erlang
> > maintainers were quite responsive to the Erlang community requests,
> > and the
> > overall quality of their releases is close to excellence.
>
> The quality wouldn't have any reason to drop as the people holding the
> "keys to the kingdom" now would still have it. But on the other hand
> the people having the desire to contribute patches or documentation
> would have an easier time doing it. Likewise, experiments based on
> erlang (loosely or tightly) would be easier for those not part of the
> core team.


My point is: we (Erlang professional users) should avoid the generation of
different Erlang flavors, based on experiments or otherwise. I think that
one of the often overlooked task of the Erlang team is keeping it up to date
on several platforms, evaluating the risks and the benefits of each single
patch, giving a warranty that no existing, deployed code will break.
They (Erlang team) have a formal procedure of doing this; my experience with
open source enthusiast is that sometime patches and upgrades are done in a
"spray and pray" mood.

Massimo


> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20080318/b46a40d3/attachment.htm>


More information about the erlang-questions mailing list