English version
Accueil     Ŕ propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis ŕ jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml ŕ l'adresse ocaml.org.

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: 2004-03-20 (16:46)
From: Gerd Stolpmann <info@g...>
Subject: Re: [Caml-list] Re: Proposed community structure (was Re: OCaml's Cathedral & Bazaar)
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

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

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