From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id pBBDXi1R015640 for ; Sun, 11 Dec 2011 14:33:44 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmkBAC6w5E7ZSMDqi2dsb2JhbAApGqpwIgEBAQoLCwcSBSKBcgEBBAE6PwULCxgJJQ8BBCghExQFh28CBiO0BIttBJoojHE X-IronPort-AV: E=Sophos;i="4.71,335,1320620400"; d="scan'208";a="122913652" Received: from fmmailgate03.web.de ([217.72.192.234]) by mail4-smtp-sop.national.inria.fr with ESMTP; 11 Dec 2011 14:33:39 +0100 Received: from moweb001.kundenserver.de (moweb001.kundenserver.de [172.19.20.114]) by fmmailgate03.web.de (Postfix) with ESMTP id D95EE1AB49E31; Sun, 11 Dec 2011 14:33:38 +0100 (CET) Received: from frosties.localnet ([95.208.118.96]) by smtp.web.de (mrweb001) with ESMTPA (Nemesis) id 0Lbrk4-1QqT9K3DV6-00k6lR; Sun, 11 Dec 2011 14:33:38 +0100 Received: from mrvn by frosties.localnet with local (Exim 4.77) (envelope-from ) id 1RZjX8-000758-2F; Sun, 11 Dec 2011 14:33:38 +0100 From: Goswin von Brederlow To: Xavier Leroy Cc: caml-list@inria.fr References: <55531934-37A5-4CC5-AB67-20CE4CCE8269@googlemail.com> <4EE37070.4010702@inria.fr> Date: Sun, 11 Dec 2011 14:33:38 +0100 In-Reply-To: <4EE37070.4010702@inria.fr> (Xavier Leroy's message of "Sat, 10 Dec 2011 15:45:04 +0100") Message-ID: <87k4639qrx.fsf@frosties.localnet> User-Agent: Gnus/5.110009 (No Gnus v0.9) XEmacs/21.4.22 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Provags-ID: V02:K0:za9SgvgEYnFA/Xw3uShf9VIEMua++Lb94fiy/df/pf0 C/5mmMxSmwHifbZzZf5wF8fcofbuf1xLMfupXmeCROYnsBVhv+ NNytED1sXinNMyREq0M/7ioKcVtda1tBYGsUaGjo2XAXzEeeTY wvu5W+cIw57lhUWJvdzpzceujhqFe71rBOdv45aZekpEFp6D8L 5GORGB5vGAD0sMKbJur3g== Subject: Re: [Caml-list] OCaml maintenance status / community fork (again) Xavier Leroy writes: > On 12/08/2011 10:10 AM, Benedikt Meurer 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. MfG Goswin