Version française
Home     About     Download     Resources     Contact us    
Browse thread
[Caml-list] Completeness of "Unix" run-time library
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ 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