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 RAA26276; Sat, 20 Mar 2004 17:46:31 +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 RAA27125 for ; Sat, 20 Mar 2004 17:46:29 +0100 (MET) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.188]) by concorde.inria.fr (8.12.10/8.12.10) with ESMTP id i2KGkSHd003626 for ; Sat, 20 Mar 2004 17:46:29 +0100 Received: from [212.227.126.160] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1B4jcC-0003CR-00; Sat, 20 Mar 2004 17:46:28 +0100 Received: from [80.129.113.18] (helo=gate.gerd-stolpmann.de) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 1B4jcC-0003UN-00; Sat, 20 Mar 2004 17:46:28 +0100 Received: from ice.gerd-stolpmann.de (ice.gerd-stolpmann.de [192.168.0.13]) by gate.gerd-stolpmann.de (Postfix) with ESMTP id C750F56B4; Sat, 20 Mar 2004 17:46:27 +0100 (CET) Received: by ice.gerd-stolpmann.de (Postfix, from userid 1000) id E6187B032; Sat, 20 Mar 2004 17:46:26 +0100 (CET) Subject: Re: [Caml-list] Re: Proposed community structure (was Re: OCaml's Cathedral & Bazaar) From: Gerd Stolpmann To: Benjamin Geer Cc: caml-list@inria.fr In-Reply-To: <405C29B7.4050006@socialtools.net> 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> <405C29B7.4050006@socialtools.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1079801186.1310.209.camel@ice.gerd-stolpmann.de> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Sat, 20 Mar 2004 17:46:26 +0100 X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:a6865a839c0178d9aa0ce41878507ea2 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 2004:99 gerd:01 stolpmann:01 gcc:01 owners:99 ocamlnet:01 camomile:01 ocamlnet:01 camomile:01 incompatible:01 cleanup:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk X-Status: X-Keywords: X-UID: 272 On Sam, 2004-03-20 at 12:23, Benjamin Geer wrote: > 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. All these projects you mention are much larger, and there are stronger interests involved that want to push the whole group into certain directions. In the short term, we will certainly not face these problems. In the long run, however, it might turn out that we will need some formalism. I think it is not a good idea to think about it _now_, because nobody has here enough experience to say which kind of formalism would be a good one. So I think this discussion has no real basis. > > 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. On the one hand, we have this situation already. For example, both ocamlnet and camomile implement aspects of Unicode, but with different intentions (ocamlnet targets at network protocols, camomile at applications). There are also a lot of incompatible database interfaces. Of course, it would be nice to have some cleanup here. On the other hand, it is problematic to enforce cooperation. If GODI tried to do that, it might happen that GODI loses overall acceptance. So I would suggest to support any such cooperation, but not to try to make pressure. In my opinion, the first goal of GODI is to get accepted by distributing software that already exists, no matter whether there are parallel solution to the same area. It may happen over time that the need for selection arises, but let us see how this can be handled. > 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. GODI is more comparable to a Linux distribution than to Linux. > > 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. IMO, the normal principles apply that everybody would expect: - Communicate the changes you are doing - Respect the work of others - Don't put in a selfish way your own interests over those of the whole group You see, these are principles, and by nature, they are quite vague. This is why I prefer the term "good practise", because it is better to see by example how general norms are applied to real matters. I am not afraid of different views on these matters and maybe conflicts that may arise, because I feel myself able to remind people of general principles that should be respected, and believe that people can act in a reasonable way. Gerd -- ------------------------------------------------------------ Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany gerd@gerd-stolpmann.de http://www.gerd-stolpmann.de ------------------------------------------------------------ ------------------- 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