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 <p...@apache.org> wrote:
----- Original Message -----
From: Rob Weir <robw...@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.
