Mailing-List: contact ooo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ooo-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of awf.aoo@gmail.com designates
 209.85.214.47 as permitted sender)
Message-ID: <50766FFC.20805@googlemail.com>
Date: Thu, 11 Oct 2012 09:06:36 +0200
From: Andre Fischer <awf.aoo@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
 rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: ooo-dev@incubator.apache.org
Subject: Re: commit after review vs lazy consensus (was Re: [DISCUSS]: next
 step towards graduation)
References: <005801cda636$c0f32f20$42d98d60$@apache.org>
 <CAP-ksogS7QnBPuFHMY+RxvSdTdngsAy4wTeWbosMcEGEwA+msA@mail.gmail.com>
 <007e01cda642$204e09d0$60ea1d70$@apache.org>
 <CAP-ksogODfOzxc7NwkWxWpTUmyHL2tO50UT03UQ6+cu2_JH0Fg@mail.gmail.com>
 <1349806240.40385.YahooMailNeo@web113514.mail.gq1.yahoo.com>
 <CAP-ksohSS2sxC7v-c2XhxrNm=MAsYhLW93h5RnXkA7_vyY+E7w@mail.gmail.com>
 <1349884618.74545.YahooMailNeo@web113504.mail.gq1.yahoo.com>
 <CAP-ksogUXzoAwaWnvcX9jFhm_ZZ+P1xXUFhoaCm-zuGz7Gr34w@mail.gmail.com>
 <1349903494.16746.YahooMailNeo@web113517.mail.gq1.yahoo.com>
 <CAP-ksojfLnaYRgkFYpDQMEfcQu+xy3gh8JG58Mc4RBVgpipemg@mail.gmail.com>
In-Reply-To: 
 <CAP-ksojfLnaYRgkFYpDQMEfcQu+xy3gh8JG58Mc4RBVgpipemg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Ahem,

Yesterday I have created issue 121191 for this, see my mail "Cleaning up 
ext_sources/" here on ooo-dev for details.
I will start deleting the files probably tomorrow, so this is a mild 
form of lazy consensus.

-Andre

On 10.10.2012 23:45, Rob Weir wrote:
> On Wed, Oct 10, 2012 at 5:11 PM, Pedro Giffuni <pfg@apache.org> wrote:
>>
>>
>>
>> ----- Original Message -----
>>> From: Rob Weir <robweir@apache.org>
>>> To: ooo-dev@incubator.apache.org
>>> 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.
>
>> http://rave.apache.org/docs/governance/lazyConsensus.html
>>
>>
>> "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:
>
> http://incubator.apache.org/openofficeorg/docs/governance/lazyConsensus.html
>
>
> -Rob
>
>
>> Pedro.