Re: commit after review vs lazy consensus (was Re: [DISCUSS]: next step towards graduation)
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.
Re: commit after review vs lazy consensus (was Re: [DISCUSS]: next step towards graduation)
Hi Andre; Silence is consent. :) Pedro. From: Andre Fischer awf@gmail.com To: ooo-dev@incubator.apache.org Sent: Thursday, October 11, 2012 2:06 AM Subject: Re: commit after review vs lazy consensus (was Re: [DISCUSS]: next step towards graduation) 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.
Re: commit after review vs lazy consensus (was Re: [DISCUSS]: next step towards graduation)
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.
