<br><br><div class="gmail_quote">On Mon, Mar 17, 2008 at 5:46 PM, Masklinn <<a href="mailto:masklinn@masklinn.net">masklinn@masklinn.net</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d"><br>
On 17 Mar 2008, at 16:39 , Massimo Cesaro wrote:<br>
<br></div>Having a full history, allowing people out of Ericsson to create<br>
patches (that could then be forwarded to the core team for inclusion)<br>
or to create temporary or permanent forks to test out features (that<br>
would probably be much rarer and harder).</blockquote><div> </div><div>Exactly my point. There's no clear advantage in doing this. <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
The first suggestion is one that is extremely well supported by DVCS:<br>
any user can clone the repository (which is the equivalent of checking<br>
it out in e.g. Subversion), then hack around (patch bugs, try to find<br>
things to cleanup, or even just create documentation patches which are<br>
already invaluable), save everything in his local repository and when<br>
needed "patchbomb" an erlang dev list (basically send revision as<br>
inline patches) so that they can be reviewed and considered for<br>
inclusion.<br>
<br>
The patchbomb step could be replaced by "attach patches to bugs" if a<br>
bug tracker is opened (the former is the way Mercurial development<br>
works, the latter is the way Django's works -- in the Python world)<br>
</blockquote><div><br>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.  <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
Conceptual integrity would be preserved because only the people who<br>
already have commit rights now would still have it, and these people<br>
would therefore have veto power over patches and suggestions, being<br>
able to enforce design decisions or style issues (and possibly ignore<br>
patches altogether if they don't have the time).<br>
<br>
DVCS would just make contributions easier by allowing everybody to<br>
hack around locally (with history) and have an history of the Erlang<br>
development for documentation as well as bug-finding (bisection<br>
search) purposes.<br>
<div class="Ih2E3d"></div></blockquote><div><br>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.<br>
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. <br>
They'll find problems because is their job to run regression testing among the other tests.<br>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.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d"><br>
><br>
> The language and its libraries are not static, they are maintained by<br>
> Ericsson in a win-win situation for the end user. Until now, the<br>
> Erlang<br>
> maintainers were quite responsive to the Erlang community requests,<br>
> and the<br>
> overall quality of their releases is close to excellence.<br>
<br>
</div>The quality wouldn't have any reason to drop as the people holding the<br>
"keys to the kingdom" now would still have it. But on the other hand<br>
the people having the desire to contribute patches or documentation<br>
would have an easier time doing it. Likewise, experiments based on<br>
erlang (loosely or tightly) would be easier for those not part of the<br>
core team.</blockquote><div> </div><div>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.<br>
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.<br><br>Massimo<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div class="Wj3C7c"><br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://www.erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://www.erlang.org/mailman/listinfo/erlang-questions</a><br>
</div></div></blockquote></div><br>