[Caml-list] Community distribution [was: OCaml maintenance status / community fork (again)]

[Benedikt Meurer <benedikt.meurer@googlemail.com>]

On Dec 11, 2011, at 14:33 , Goswin von Brederlow wrote:

>>> The relevant bug report PR/5404, which includes a backward
>>> compatible patch, is already waiting for a sign of life for 3 weeks
>>> now (maybe wait another 4 years to get the port fixed).
>> 
>> More bile.  What's so urgent about it?  The next release of OCaml is 3-6
>> months in the future; your suggestion will be examined by then.  You know,
>> some people have busy professional lives. I can only devote 1 to 2 days per
>> months to OCaml maintenance, and would prefer to spend them on technical
>> work rather than on massaging egos or putting out the fires that you light
>> up on this list.
> 
> I don't want to be aggressive or offensive and if it comes across as
> that then please forgive me. No need to massage my ego also. I would
> rather be told to piss off or that a patch will never be added because
> it is stupid than have you play nice and have patches be left unatended
> in mantis. Because how else will I ever learn?  That said ...
> 
> So maybe PR/5404 was a bad example. How about these?
> 
> [1] 1 month to acknowledge, 24 month silence since then
> [2] 1 month to acknowledge, 24 month silence since then
> [3] 11 month to acknowledge, 19 month silence since then
> [4] 16 month to acknowledge, 18 month silence since then
> [5] 15 month to acknowledge, 6 month silence since then
> 
> [1] http://caml.inria.fr/mantis/view.php?id=4919
> [2] http://caml.inria.fr/mantis/view.php?id=4909
> [3] http://caml.inria.fr/mantis/view.php?id=4812
> [4] http://caml.inria.fr/mantis/view.php?id=4987
> [5] http://caml.inria.fr/mantis/view.php?id=5005
> 
> All of these have patches (or just needs a function declaration copied to
> the .h file). They don't need huge work consuming changes to the
> compiler and they don't add anything fundamentally new to it. They just
> improve/extend the existing stuff a little.
> 
> For those to lazy to follow the links here is one of the patches that
> has been sitting there for 2 years now:
> 
> ----------------------------------------------------------------------
> --- ocaml-3.11.0.orig/otherlibs/unix/unixsupport.h
> +++ ocaml-3.11.0/otherlibs/unix/unixsupport.h
> @@ -20,6 +20,7 @@
> #define Nothing ((value) 0)
> 
> extern value unix_error_of_code (int errcode);
> +extern int code_of_unix_error (value error);
> extern void unix_error (int errcode, char * cmdname, value arg) Noreturn;
> extern void uerror (char * cmdname, value arg) Noreturn;
> 
> --- ocaml-3.11.0.orig/otherlibs/unix/unixsupport.c
> +++ ocaml-3.11.0/otherlibs/unix/unixsupport.c
> @@ -263,6 +263,15 @@
>   return err;
> }
> 
> +extern int code_of_unix_error (value error)
> +{
> +  if (Is_block(error)) {
> +    return Int_val(Field(error, 0));
> +  } else {
> +    return error_table[Int_val(error)];
> +  }
> +}
> +
> void unix_error(int errcode, char *cmdname, value cmdarg)
> {
>   value res;
> ----------------------------------------------------------------------
> 
> Adding this does not take a week of your summer vacation but still it
> gets ignored.
> 
> Sure it is more fun to write code for first-class modules and the core
> team has done a great job there. On the other hand trvial things are not
> being done and that is verry frustrating to the submitter. Frankly I've
> given up writing patches for ocaml because what is the point. They are
> not getting looked at. Through things like that you are loosing a
> workforce that could contribute at lot.
> 
> On the other hand if the model of glibc / eglibc for example where used
> for ocaml the frustration would be reduced, the patches would get
> audited by others in the community and added to the one community "fork"
> before reaching the core team. You would get less patches, patches that
> are better tested and cleaner. "Bad" patches would get filtered out
> before they reach you.
> 
> This is not a condemnation of you or the core team. It is probably not
> even something you can do anything about no matter how hard you try. It
> is probably just a matter of scale. As a project growes at some point
> there just seem to be a point where a single central core doesn't work
> anymore. Things pile up, things fall through the cracks, priotization
> leaves things starving. There plain aren't enough hours in the day to
> cover every single bug or reply to every mail on the mainlinglist.
> 
> So let the community help and offload some work on them, like vetting a
> simple patch like the above, so that you have more time to concentrate on the
> difficult things like arm support or fist class modules (which I love by
> the way) or to take a deserved vacation.

I fully agree, and as mentioned earlier, I'll help to maintain such a community distribution (or whatever we will call that glibc/eglibc thing for OCaml). Adding to the list above, a community distribution would provide an additional benefit for the users/community: We could release patch sets often and early while regular OCaml releases appear only every year or two. As Goswin already mentioned, big eye-catchers like first class modules are nice, but fixing the bugs (i.e. PR/4863, trivial patch from a core member(!) waiting to be applied for 3 months) is even more important (although probably less interesting from the core hackers point of view).

> MfG
>        Goswin

greets,
Benedikt