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


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