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 SAA29247; Fri, 19 Mar 2004 18:30:17 +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 SAA24337 for ; Fri, 19 Mar 2004 18:30:15 +0100 (MET) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.176]) by concorde.inria.fr (8.12.10/8.12.10) with ESMTP id i2JHUEHd001101 for ; Fri, 19 Mar 2004 18:30:15 +0100 Received: from [212.227.126.160] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1B4Np0-0001ie-00; Fri, 19 Mar 2004 18:30:14 +0100 Received: from [80.129.103.122] (helo=gate.gerd-stolpmann.de) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 1B4Np0-0003YQ-00; Fri, 19 Mar 2004 18:30:14 +0100 Received: from ice.gerd-stolpmann.de (ice.gerd-stolpmann.de [192.168.0.13]) by gate.gerd-stolpmann.de (Postfix) with ESMTP id B4C0D5721; Fri, 19 Mar 2004 18:30:13 +0100 (CET) Received: by ice.gerd-stolpmann.de (Postfix, from userid 1000) id E82D6B035; Fri, 19 Mar 2004 18:30:12 +0100 (CET) Subject: [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: <405AEB1D.6040109@socialtools.net> References: <4059994E.2010802@socialtools.net> <20040318151234.B21768@pauillac.inria.fr> <1079653304.990.89.camel@ice.gerd-stolpmann.de> <405AEB1D.6040109@socialtools.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1079717412.1319.83.camel@ice.gerd-stolpmann.de> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Fri, 19 Mar 2004 18:30:12 +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; ocaml's:01 gerd:01 stolpmann:01 fre:99 2004:99 44,:01 gerd:01 stolpmann:01 owners:99 owners:99 reviews:99 python's:01 peps:01 incompatible:01 viktoriastr:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk X-Status: X-Keywords: X-UID: 239 On Fre, 2004-03-19 at 13:44, Benjamin Geer wrote: > Gerd Stolpmann wrote: > > In order to reach this goal, a number of questions should be answered > > (best as some kind of community process): > > > > - How can people participate (add packages, fix bugs, improve the base > > software)? > > > > - How can the quality be ensured? > > > > - How are decisions made? > > > > - How can the platform be kept open? > > How about a structure like this: > > * A GCC-like steering committee composed of very > experienced, respected Caml developers, who would be > responsible for setting overall policy and resolving > conflicts in the community. 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. > * Mozilla-like module owners, designated by the > steering committee. Module owners would review and > accept patches for their modules after public > discussion. 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. Technically, I don't plan any sort of access control, i.e. everybody with an account can change everything. Of course, it is bad practise to change the package maintained by somebody else without notification. I simply believe that a good practise of cooperation is better than formal rules. > * Rotating GCC-like release managers, also chosen by the > steering committee. The release managers would be > responsible for coordinating regular releases and > determining when each release was ready. It is currently unclear for me whether we should have releases at all. GODI has the ability to update every package separately, so what is a release? Of course, for the outer world a formal release is something valuable. We definitely need a process to determine when each package is ready for release. We'll see how to do that. > People could participate by posting proposals to a mailing list; > discussion would ensue, and the relevant module owner would be expected > to accept or reject the proposal within a reasonable amount of time, > taking into account the consensus on the list. A Mozilla-like review > process could be used: the author submits a patch, the module owner > reviews it and requests changes, and they iterate until the module owner > is satisfied. For major enhancements, a more formal, detailed proposal > format could be used, like Python's PEPs. There is now a mailing list, see the separate announcement. I think we will see whether we need formal rules or not. This depends a lot of parameters that are currently uncertain, e.g. the number of developers. > If INRIA was willing, such a structure could also take over development > of the standard libraries. I guess they have their own internal process which is incompatible with such a structure. 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