On Fri, Oct 01, 1999 at 10:14:00AM +0200, Stephane Bortzmeyer wrote: > > This is exactly analogous to, say, the selection of thread implementations > > for glibc 2.0. You are still free to use some other thread model if you care > > to, but the default one that most people write to is the one in glibc that > > is bound to the kernel threads. > > OK, I get it. But the arbitration mechanism in glibc is clear: the maintainer > of glibc decides what will be the default thread library and what will be > left outside. > > It means our packaging scheme would need a maintainer, to take such > decisions. This job will require knowledge, diplomacy and authority. > > Some cases are simple, like XML (there is only one implementation). Regexps > will be more complicated.
Agreed. However, I think that it makes plenty of sense to have more than one maintainer on a project such as this. There are already projects in Debian that have overwhelmed the single maintainer model and the project has responded with things like the X Strike Force, or even the Debian-Java list (which is a little less formal and integrated). In general, I think that such a project could be broken up into pieces and design decisions could be made in a largely diplomatic manner. It would still be advisable to have some kind of tie-breaking mechanism or a lead designer to keep a single architectural vision. -- __________________________________________________________________ Ean Schuessler A guy running Linux Novare International Inc. A company running Linux *** WARNING: This signature may contain jokes.
