This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Concensus-based community-driven development.


On Wed, 4 Apr 2012, Andreas Jaeger wrote:

> * What patch will be committed without review? E.g. should a machine
> maintainer commit directly? Should we have - like gcc has - a role that states
> that obvious patches are fine?

Obvious patches should generally be allowed.

Where we say "machine maintainer" I think it should be "subsystem 
maintainer" - we should have such people for more subsystems than just 
particular architecture ports (e.g. libm, NPTL, GNU Hurd support, 
locales).  And I think it should be up to subsystem maintainers to judge 
whether they have the expertise in a particular case to commit a patch 
without prior third-party review (this may vary from patch to patch), 
though for some cases (e.g. x86) we may choose to have third-party review 
for all patches.

> * What does consensus mean? If somebody sends a patch, I review it and ack it
> and nobody complains in say 24 hours - did we reach consensus? Or can it get
> committed directly? Whose positive review counts?

For a lot of patches that are not obvious, but don't involve any general 
design issues or anything likely to be controversial, I don't think a 
24-hour delay (given that someone has sanity checked the reasoning behind 
the patch, and the conformance of the patch to coding standards etc.) 
serves a useful purpose; it just unduly complicates people building 
subsequent fixes on top of the patch.

> * There are several patches on the mailing list where people ask for review
> and nothing happens - including the x86-64 memcpy patch that I send. What
> happens if nobody reviews a patch?

Ping it, CC:ing relevant maintainers as appropriate.

> I also agree with Pasky that we should be liberal in some places (note: We
> should not be too liberal in adding new functions ;) to avoid bottlenecks.
> There are very few active people and thus we should not overload them,

Yes.  Apart from being liberal regarding subsystem maintainers it may also 
be useful to have some subset of committers trusted to judge which of 
their patches are straightforward and uncontroversial and commit those 
without prior review (but still with the usual posting of patch and 
explanation to libc-alpha).

-- 
Joseph S. Myers
joseph@codesourcery.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]