From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id pBBDxcsA017241 for ; Sun, 11 Dec 2011 14:59:40 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AukAAL625E5KfVM2kGdsb2JhbAApGqpoCCIBAQEBCQkNBxQEIYFyAQEBAwESAiYGAQE3AQQLPxI0AQUBHAYnBQmHZgIGI5d+CoozhBwBjR0HiwpjomY9g3o X-IronPort-AV: E=Sophos;i="4.71,335,1320620400"; d="scan'208";a="134908324" Received: from mail-ee0-f54.google.com ([74.125.83.54]) by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 11 Dec 2011 14:59:39 +0100 Received: by eekc50 with SMTP id c50so3066516eek.27 for ; Sun, 11 Dec 2011 05:59:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=SfSy9YE5Dgm+uLund78n9IEIJ60F2rqc1pS4z6OlkoQ=; b=JTAlvU3UFNSlco8dbTBM1sE1pvZimm2o1uOMnWovTr2mGAWbJxhu7W795nH4JG5y/S /phFEXBXPjggQZV1TagnTWSn9zdVGmXb8aVsjMKbR/8rgZ11JhW/09meZBpiJf+T5zn7 jIAtfkdgih0rD5TOs8h0OPLp5Ex28u8/BfBCk= Received: by 10.14.14.77 with SMTP id c53mr2015955eec.85.1323611978685; Sun, 11 Dec 2011 05:59:38 -0800 (PST) Received: from coruscant.kosmos.all (ip-95-223-170-32.unitymediagroup.de. [95.223.170.32]) by mx.google.com with ESMTPS id a60sm61369071eeb.4.2011.12.11.05.59.36 (version=SSLv3 cipher=OTHER); Sun, 11 Dec 2011 05:59:37 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Benedikt Meurer In-Reply-To: <87k4639qrx.fsf@frosties.localnet> Date: Sun, 11 Dec 2011 14:59:34 +0100 Cc: Xavier Leroy , caml users , Caml-devel developers Message-Id: <65A8AFE2-17CC-45C1-B57B-80D631C038AA@googlemail.com> References: <55531934-37A5-4CC5-AB67-20CE4CCE8269@googlemail.com> <4EE37070.4010702@inria.fr> <87k4639qrx.fsf@frosties.localnet> To: Goswin von Brederlow X-Mailer: Apple Mail (2.1251.1) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by walapai.inria.fr id pBBDxcsA017241 Subject: [Caml-list] Community distribution [was: OCaml maintenance status / community fork (again)] 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