incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <>
Subject Re: commit after review vs lazy consensus (was Re: [DISCUSS]: next step towards graduation)
Date Wed, 10 Oct 2012 21:45:05 GMT
On Wed, Oct 10, 2012 at 5:11 PM, Pedro Giffuni <> wrote:
> ----- 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:

Actually, is not wrong at all.  I think you are confusing two
different things:  1) *assuming* lazy consensus and 2) stating lazy
consensus.  When you JFDI you are assuming lazy consensus. When you
state it and wait 72 hours you are being more careful, leaving more
room for doubt.

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

For items that you think may be controversial you *should* state lazy
consensus and give 72 hours to object.  Otherwise you risk wasting
your time, since any committer can veto your commit.  Better to know
that up front than after the fact and be forced to revert your change.
 We know that this doesn't scale, since it can lead to week's of
broken builds, as you know.

I'm assuming you actually understand the above and are merely being
argumentative.  So I'll stop my co-enablement of this pointless
discussion after this post.

And btw, as a PMC member you might get into the practice of quoting
this project's statement of this practice rather than hunting for it
on unrelated websites:


> Pedro.

View raw message