incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pedro Giffuni <>
Subject commit after review vs lazy consensus (was Re: [DISCUSS]: next step towards graduation)
Date Wed, 10 Oct 2012 21:11:34 GMT

----- Original Message -----
> From: Rob Weir <>
> To:
> Cc: 
> Sent: Wednesday, October 10, 2012 11:05 AM
> Subject: Re: [DISCUSS]: next step towards graduation
> On Wed, Oct 10, 2012 at 11:56 AM, Pedro Giffuni wrote:
>>  ----- Original Message -----
>>  ...
>>>>   Who "praised" my axe? I recall *you* threatened to veto 
> it :-P.
>>>  Yes, I did.  And I've learned from my error.  So in this case 
> I'd seek
>>>  lazy consensus first ;-)
>>>>   And now that you bring back the issue, I still think the cat-B 
> files have
>>>>  to be delete *before* graduation.
>>>  Are there some still that you want to delete?  Is anything stopping
>>>  you?  Is there a BZ issue for this?
>>  For the record: I said axe was a proper solution for the issue, I 
> didn't
>>  offer to axe them myself. :)
>>  IMHO, opening a bugzilla for this issue is against the concept of lazy
>>  consensus: there is consensus that we want to graduate so we
>>  remove those files and if someone complains we consider alternatives.
> Lazy consensus is when you want to do something yourself but you think
> it might be controversial.  If you think it is not controversial, and
> it is reversible (as almsot everything in SVN is) then JFDI.

Wrong concept:

"Lazy Consensus means that when you are convinced that you know what the community would like
to see happen you can simply assume that you already have consensus and get on with the work.
You don't have to insist people discuss and/or approve your plan, and you certainly don't
need to call a vote to get approval. You just assume you have the communities support unless
someone says otherwise."

For controversial issues there is the 72 hours rule, but lazy consensus strictly speaking,
does not depend on controversiality.The idea is that once we name someone committer, he/she
is expected to have criteria to advance on his own, and although some mentorship may be optional
we don't expect a committer to depend on others to review and approve..

What doesn't scale IMHO.. is that committers *have* to ask for review, at least it doesn't
seem the Apache way to me.


View raw message