From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id UAA13745; Sat, 24 Apr 2004 20:24:04 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id UAA14393 for ; Sat, 24 Apr 2004 20:24:01 +0200 (MET DST) Received: from rabelais.socialtools.net (rabelais.socialtools.net [81.2.94.243]) by nez-perce.inria.fr (8.12.10/8.12.10) with ESMTP id i3OIO0jq018853 for ; Sat, 24 Apr 2004 20:24:00 +0200 Received: by rabelais.socialtools.net (Postfix, from userid 108) id F08A72332F; Sat, 24 Apr 2004 19:23:59 +0100 (BST) Received: from socialtools.net (chaucer.socialtools.net [81.2.94.242]) by rabelais.socialtools.net (Postfix) with ESMTP id DCFE2232DE; Sat, 24 Apr 2004 19:23:58 +0100 (BST) Message-ID: <408AB0A9.9040904@socialtools.net> Date: Sat, 24 Apr 2004 19:23:37 +0100 From: Benjamin Geer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-gb, en, fr, it MIME-Version: 1.0 To: "Brandon J. Van Every" Cc: caml Subject: Re: [Caml-list] RE: Proposal: community standard library project References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on rabelais.socialtools.net X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Miltered: at nez-perce by Joe's j-chkmail ("http://j-chkmail.ensmp.fr")! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 brandon:99 bow:01 persist:01 124.:99 kernel:01 feasible:01 maintainers:02 maintainers:02 patches:02 wrote:03 library:03 docs:03 let:04 pthreads:05 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk Brandon J. Van Every wrote: > I don't easily swallow "no duplicate functionality," however. Libraries > have to prove their worth in the field somehow. I think the Linux kernel developers have a good way of handling this: if there are two competing libraries that do the same thing, they both stay outside the project, as patches, until there is a consensus about which is better; then the maintainers include one of the libraries in the project, and the other one takes a bow and honourably leaves the stage.[1] The maintainers' job is to ensure that this process is neither too long nor too short. It's OK to have two libraries that do the same thing for a short time, in order to choose the best approach; but in the long term, duplication leads to wasted effort. Therefore, both libraries should have a chance to prove themselves; but if after a certain amount of time there is no clear consensus about which is better, and it is not feasible to combine the best aspects of both, the maintainers should use their own judgement and pick one of them, which is what Linus does. It is better to resolve conflicts and move on than to let them persist endlessly. Ben [1] For a good example of this, see: http://www-124.ibm.com/pthreads/docs/announcement ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners