openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <robw...@apache.org>
Subject Re: Proposal: How we should handle committer vetos and reverts in the future
Date Fri, 15 Feb 2013 19:21:53 GMT
On Fri, Feb 15, 2013 at 2:19 PM, Rob Weir <robweir@apache.org> wrote:
> On Fri, Feb 15, 2013 at 9:40 AM, janI <jani@apache.org> wrote:
>> On Feb 15, 2013 3:25 PM, "Greg Stein" <gstein@gmail.com> wrote:
>>>
>>> On Fri, Feb 15, 2013 at 09:11:13AM -0500, Rob Weir wrote:
>>> > On Fri, Feb 15, 2013 at 8:57 AM, Rob Weir <robweir@apache.org> wrote:
>>> > > On Fri, Feb 15, 2013 at 8:45 AM, Greg Stein <gstein@gmail.com>
wrote:
>>> > >> On Thu, Feb 14, 2013 at 05:31:43PM -0500, Rob Weir wrote:
>>> > >>> Obviously the changes to Calc's POWER() function did not go
well.
>>> > >>>
>>> > >>> IMHO, we need to better respect the rare but powerful veto
option
>> that
>>> > >>> committers have:
>>> > >>>
>>> > >>> http://www.apache.org/foundation/glossary.html#Veto
>>> > >>>
>>> > >>> When a committ is vetoed, it should be reverted quickly.
>> Remember, a
>>> > >>
>>> > >> No. This is flat out incorrect.
>>> > >>
>>> > >> A veto means you cannot *ship* with that change in there. It can
>> stick
>>> > >> around as long as necessary, but must eventually be pulled out
when
>>> > >> the code is shipped.
>>> > >>
>>> > >
>>> > >
>>> > > If this is true then you have a Foundation document which is incorrect
>>> > > and needs to be changed, since it is totally out of synch with what
>>> > > you are saying:
>>>
>>> Not surprised.
>>>
>>> > And Greg, just to be perfectly clear and to avoid any misunderstanding
>>> > here, I'm not arguing against your interpretation.  If that is the
>>> > consensus view then I'm happy to adopt it as my own.  I'm just
>>> > pointing out that you have a prominent page on the website that, to
>>> > the uninitiated, appears to say something entirely different.  Phrases
>>> > like "forces it to be reverted" and "may not be overridden nor voted
>>> > down" are quite strong statements.
>>>
>>> Any change can be vetoed at any time. There is no statute of
>>> limitations, except for making a release. (http://s.apache.org/j4)
>>>
>>> Thus, "bad" code can sit around in version control for a very long time.
>>>
>>> The "forces it to be reverted" is in reference to making a release.
>>>
>>> Obviously, the community doesn't want to wait that long. Ripple
>>> effects can make it hard to revert the change later. This is why you
>>> start the discussion and come to consensus on how to proceed.
>>>
>>> In my experience, "proceed" usually means additional changes to
>>> address the concerns raised. The only time "revert" has ever been the
>>> solution is when somebody has added huge new chunks of code that the
>>> community doesn't agree with [in terms of direction].
>>>
>>> There is quite a bit of history in the httpd project discussing what
>>> "veto" means, and how to handle them. I summarize all those years with
>>> the simple phrase, "veto means a discussion is needed".
>>>
>> thanks for putting some sense into this discussion. I totally agree with
>> your point of view.
>>
>> and please remember accepting "backwards compatibility" as a technical
>> argument is real killer which can be used to 99℅ of all commits. So
>
> Then I guess we're all darn fortunate that no one has used a backwards
> compatibility argument to veto 99% of all commits.
>
> Of course, in specific instances, where we are dealing with external
> interfaces that we have traditionally preserved constant, which users
> depend on, and where no discussion has occurred or consensus reached
> to break that compatibility, then this can be a valid technical reason
> for a veto.
>

E.g., does anyone actually think that if I checked in code to reverse
the SIN() and COS() functions, that this code could not be vetoed on
technical grounds?

> -Rob
>
>> starting a discussion makes sense whena committer has concern, but using a
>> veto based on "backwards compatibility" to revert is pure anarchy.
>>
>> rgds
>> jan i
>>> Cheers,
>>> -g

Mime
View raw message