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 MAA11769; Sat, 20 Mar 2004 12:23:40 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id MAA11878 for ; Sat, 20 Mar 2004 12:23:38 +0100 (MET) Received: from rabelais.socialtools.net (rabelais.socialtools.net [81.2.94.243]) by concorde.inria.fr (8.12.10/8.12.10) with ESMTP id i2KBNbHd004430 for ; Sat, 20 Mar 2004 12:23:37 +0100 Received: by rabelais.socialtools.net (Postfix, from userid 108) id 21096232FE; Sat, 20 Mar 2004 11:23:37 +0000 (GMT) Received: from socialtools.net (chaucer.socialtools.net [81.2.94.242]) by rabelais.socialtools.net (Postfix) with ESMTP id ADD53232FD; Sat, 20 Mar 2004 11:23:35 +0000 (GMT) Message-ID: <405C29B7.4050006@socialtools.net> Date: Sat, 20 Mar 2004 11:23:35 +0000 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: Gerd Stolpmann Cc: caml-list@inria.fr Subject: Re: [Caml-list] Re: Proposed community structure (was Re: OCaml's Cathedral & Bazaar) References: <4059994E.2010802@socialtools.net> <20040318151234.B21768@pauillac.inria.fr> <1079653304.990.89.camel@ice.gerd-stolpmann.de> <405AEB1D.6040109@socialtools.net> <1079717412.1319.83.camel@ice.gerd-stolpmann.de> In-Reply-To: <1079717412.1319.83.camel@ice.gerd-stolpmann.de> 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 concorde by Joe's j-chkmail ("http://j-chkmail.ensmp.fr")! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 ocaml's:01 gerd:01 stolpmann:01 gcc:01 owners:99 unicode:01 kernel:01 kernel:01 leader:97 patch:02 modules:02 unix:02 leaders:97 module:03 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk X-Status: X-Keywords: X-UID: 267 Gerd Stolpmann wrote: > I hope we don't need such a committee. First we should try to seek a > consensus. I suppose this will almost always be successful, and over > time we will have a situation where the voices of some people will have > more weight than the voices of others, simply because they are naturally > respected. > > So I would suggest to postpone such a committee until it is really > needed, when everything else failed. OK. I think eventually, though, we will need an explicit process for resolving conflicts. On some projects, the process is simply that when there is a conflict, the leader makes a decision. Good free-software project leaders are mainly people whose judgement is respected, and who are good at mediating between people with conflicting opinions. I don't think we have one single person who would clearly be the best one for that role, so I suggested a group, which seems to work well for GCC. Another way is to vote, as Debian does. But you can't vote every day; there still need to be people who are trusted by the community to settle important questions. In Mozilla, these are module owners and super-reviewers. > GODI currently has packages which are comparable with modules. Every > package has a maintainer. Initially, the maintainer is the person who > adds the package to the repository. What concerns me is that we could end up with redundant packages in the repository. I think it would be awful to have five different competing versions of the Unix module or the List module, or five different attempts to implement Unicode support. I think the structure of the project should require people to pool their efforts. On the Linux kernel, this is done very simply: since people working on the same problem know that only one patch will be accepted into the official kernel, they have a strong incentive to cooperate. If they can't cooperate because their work is too different, Linus chooses what he thinks is the better solution. This works because Linus takes into account the consensus of the community, but I don't think it would work without Linus, or without a Linus-like process. > I simply believe that a good practise of cooperation is better than > formal rules. Not everyone knows how to cooperate well. It may be better to say explicitly what a good practice of cooperation is. Ben ------------------- 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