Browse thread
[Caml-list] Completeness of "Unix" run-time library
-
Vasili Galchin
- james woodyatt
-
Richard Jones
-
Shawn Wagner
-
Eric Stokes
-
Vasili Galchin
-
Eric Stokes
-
Vasili Galchin
-
Matt Gushee
-
Richard Jones
-
Nicolas Cannasse
- Diego Olivier Fernandez Pons
- Wolfgang Müller
-
John Carr
-
Richard Jones
-
oliver@f...
-
John Carr
-
Richard Jones
- Jacques Garrigue
- Benjamin Geer
- Michael Vanier
- Sven Luther
-
Richard Jones
- Sven Luther
-
John Carr
-
oliver@f...
-
Richard Jones
-
Nicolas Cannasse
- Shawn Wagner
- Vasili Galchin
- Vasili Galchin
-
Richard Jones
-
Matt Gushee
-
Vasili Galchin
-
Eric Stokes
-
Vasili Galchin
-
Eric Stokes
-
Shawn Wagner
- Stefano Zacchiroli
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| From: | Benjamin Geer <ben@s...> |
| Subject: | Re: [Caml-list] Re: Proposed community structure (was Re: OCaml's Cathedral & Bazaar) |
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