This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Concensus-based community-driven development.
On Thu, 5 Apr 2012, Carlos O'Donell wrote:
> (1) Trivial bug-fix changes.
>
> Obvious patches can be committed without review.
>
> I've written up a page on "Consensus" here to try clarify some of the
> current community attitude:
>
> http://sourceware.org/glibc/wiki/Consensus
There are several other types of obvious/trivial patches (I'm not clear on
the distinction you seem to be making between "trivial" and "obvious"),
including:
* Regenerating a file someone previously failed to regenerate, with the
same version of the relevant tool such as autoconf. No need to post the
patch, although it may be useful to mention the change.
* Fixing a coding standards problem in a recently committed patch.
* Adding a bug number to ChangeLog, NEWS or both. No need to post the
patch.
* Adding missing #include directives where it is clear what the right
header is for functionality used in a source file.
* Adding LOCPATH settings for a testcase using locales.
* Fixing code typos in a commit (e.g. from last-minute untested changes)
that break the build or testing, where it is clear what the right fix is.
> In general I think you should seek out two other people to review any
> non-trivial patches.
I think two other people is overkill for the vast majority of patches; one
should be enough unless it seems there is likely to be some controversy
(that first reviewer is always free to say that they'd like to see other
opinions, if they don't think their review should be enough to put the
patch in on its own, but the default should be one review is enough). Of
course if we can get subsystem maintainers covering most/all of libc
(which I think we should have ... we should list a set of areas covering
libc, and try to find people for them), that one review can be from
someone confident of their expertise in the code; someone reviewing a
patch in an area where they lack more specific expertise may be more
likely to call for other opinions.
--
Joseph S. Myers
joseph@codesourcery.com