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, Apr 5, 2012 at 5:56 AM, Joseph S. Myers <joseph@codesourcery.com> wrote:
> 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.

Please adjust the Consensus page with your comments.

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

Could you adjust the Consensus page accordingly?

That way after you make your adjustments we can all go read the text
and continue commenting.

Cheers,
Carlos.


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