This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Concensus-based community-driven development.
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