Concensus-based community-driven development.

[Andreas Jaeger]

On 04/04/2012 08:42 PM, Carlos O'Donell wrote:
> I've adjusted the wiki to indicate that
> prime mover is consensus. Patches should
> be posted to libc-alpha, reviewed, discussed,
> and then committed.
>
> The machine maintainers are people who have
> assumed a role of leadership when it comes
> to the code for the machine they are maintaining.
>
> http://sourceware.org/glibc/wiki/MAINTAINERS#Maintainers_for_libc_and_ports_add-on
>
> Comments?

Thanks a lot for starting this discussion. I have - like Pasky in his 
email - a couple of questions:
* 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?

* 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?

* 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?

I agree that every patch (with the exception of regeneration of e.g. 
configure files) should be send to the list before committing it.

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,

Andreas
-- 
  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
   SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
    GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg)
     GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126