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 pB8B7TZ0021833 for ; Thu, 8 Dec 2011 12:07:29 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar0CAAyZ4E6K54gDgWdsb2JhbAApGqplIgEBFiYlgXIBAQUyATsKARALGAkWDwkDAgECAUUGDQEHAhCHeyO2Wos7BJRrhUuMXA X-IronPort-AV: E=Sophos;i="4.71,319,1320620400"; d="scan'208";a="134528085" Received: from rouge.crans.org ([138.231.136.3]) by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/ADH-AES256-SHA; 08 Dec 2011 12:07:19 +0100 Received: from localhost (localhost.crans.org [127.0.0.1]) by rouge.crans.org (Postfix) with ESMTP id 6525C85E2; Thu, 8 Dec 2011 12:07:19 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at crans.org Received: from rouge.crans.org ([10.231.136.3]) by localhost (rouge.crans.org [10.231.136.3]) (amavisd-new, port 10024) with LMTP id IG-Okv5UPneM; Thu, 8 Dec 2011 12:07:19 +0100 (CET) Received: from [152.81.3.42] (wencory.loria.fr [152.81.3.42]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by rouge.crans.org (Postfix) with ESMTPSA id 4249F85E1; Thu, 8 Dec 2011 12:07:19 +0100 (CET) Message-ID: <4EE09A66.9020306@glondu.net> Date: Thu, 08 Dec 2011 12:07:18 +0100 From: =?ISO-8859-1?Q?St=E9phane_Glondu?= User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111114 Icedove/3.1.16 MIME-Version: 1.0 To: Benedikt Meurer CC: caml users References: <55531934-37A5-4CC5-AB67-20CE4CCE8269@googlemail.com> In-Reply-To: <55531934-37A5-4CC5-AB67-20CE4CCE8269@googlemail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [Caml-list] OCaml maintenance status / community fork (again) On 12/08/2011 10:10 AM, Benedikt Meurer wrote: > [...] I'm already pissed off by the fact that it will probably take ages for someone to even respond to the patch, not to mention that it will take forever to get it out to the users (well maybe Debian will include the patch for armhf, but that means the Debian developers have to do upstream work...). As a maintainer of OCaml (among other things) in Debian, I must agree with you that slow reaction, opacity in its development process, etc. make OCaml a very frustrating upstream (one of the worst I have to deal with). See for example: http://caml.inria.fr/mantis/view.php?id=4963 http://caml.inria.fr/mantis/view.php?id=5131 http://caml.inria.fr/mantis/view.php?id=5254 http://caml.inria.fr/mantis/view.php?id=5279 http://caml.inria.fr/mantis/view.php?id=5393 All very precise bugreports with rather trivial patches or suggestions. Yet, no satisfactory reaction. I once proposed a patch to "fix" the "-custom" behaviour that made resulting executables not strippable, to avoid all sort of special-casing that had to be done in Debian (and Fedora) because of this behaviour. It has been rejected (but I applied it nonetheless to the Debian package). See the discussion at: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=256900 (in particular, starting from message #42). All this often leads me to just not trying to solve bugs in OCaml myself, even for things that do affect Debian. See for example: http://caml.inria.fr/mantis/view.php?id=1710 http://caml.inria.fr/mantis/view.php?id=1711 http://caml.inria.fr/mantis/view.php?id=1836 http://caml.inria.fr/mantis/view.php?id=4812 http://caml.inria.fr/mantis/view.php?id=5371 Concerning your work on ARM, PR#5049 completely deterred me from working on it myself, or submitting it to more competent people (and I do know some thanks to Debian and Ubuntu). I really think that OCaml could benefit from a more open development model, and should leverage external contributors (that are not members of the consortium) instead of plainly ignoring them. There is for example no need for someone in the "core team" to feel responsible for the ARM port. Have a look at: https://bugs.launchpad.net/ubuntu/+source/ocaml/+bug/810402 People who care about ARM solved the bug themselves. Having ocamlopt working on all Debian architectures wouldn't look so unreasonable if the "core team" were willing to integrate necessary changes as part of official releases (which is clearly not the case). I'm not advocating for faster development, endless addition of new features, or a better standard library, I just wish better reactivity to the community concerning the compiler or the language itself. The general lack of "official" (whatever that means) participation in this mailing-list is another example of this problem. Cheers, -- Stéphane