Re: Syncing platform-specific bits with generic code

["Carlos O'Donell" <carlos at redhat dot com>]

On 02/20/2013 12:06 PM, Siddhesh Poyarekar wrote:
>> If something is missing form the Consensus page then we need to gather
>> consensus and add it?
> 
> I was proposing instead that we allow maintainers to use their
> judgement in considering what is obvious and reviewers give feedback
> if a commit was not 'obvious' and ought to have been discussed since
> there is a possibility of disagreement.  Based on this, we can put in
> *exclusions* to the obvious commit rule rather than inclusions.

I understand your position now. Thank you for clarifying that.

I don't believe that a permissive attitude towards obvious changes
is the best fit for the community *today*.

There are many many subtle details in the library that may seem
obvious, but in fact require significant experience or review to
implement correctly or with a high QoI.

Therefore we've adopted a conservative consensus of allowed obvious
changes rather than the other way around.

I'm going to use Thomas Schwinge as an example here. Thomas is
an *excellent* developer. This morning he checked in an "obvious"
fix to the MIPS nan.h installed header. Unfortunately the fix
used a gcc attribute name that was in the user's namespace e.g.
used vs. __used__. Joseph and I caught the problem. 
It took 3 people to ensure that we had a high quality change.
I don't blame Thomas at all, I make worse mistakes all the time,
it's hard to get all the details right. The strength of the
community is in the review.

What does this mean? As a community we've lost a good portion
of our knowledge and experience over the years and we're slowly
building it back.

One day we'll reach the tipping point where the consensus list will
be so large that we'll all look at each other, now seasoned core
C library developers, and agree that it should be inverted.

I do not believe we are there yet :-)

Cheers,
Carlos.