----- Messaggio originale -----
> Da: Rob Weir
> On Thu, Feb 14, 2013 at 8:49 PM, Pedro Giffuni <[email protected]> wrote:
>> 
>> 
>>  ----- Messaggio originale -----
>>>  Da: Rob Weir
>> 
>> 
>>>  Inviato: Giovedì 14 Febbraio 2013 17:31
>>>  Oggetto: Proposal: How we should handle committer vetos and reverts in 
> the future
>>> 
>>>  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
>>> 
>> 
>>  Rare is the correct term. It seems to me like a last resort and that is 
>> likely to require some discussion. If I change is obviously broken you
>> don't  issue a veto, you simply discuss it. a veto is nowhere near being
>> resolved within minutes.
>> 
> 
> We had already had the longest thread in this project's history before
> your patch received two vetoes.  You can not say that it was not
> discussed.
> 

I do think the size of the flamefest has no correspondence with the
scope of the original patch.
Few real argumentation was given and I asked for more time to
evaluate the impact of the change, which I still retain was very small.


> And remember, a veto is a power of an individual committer.  It is not
> a collective right.  We vote in committers because we think they will
> use this power carefully.  We also vote in committers because we think
> that they will handle things properly if their changes are also
> vetoed.  We trust our committers to do these things.
> 
>> 
>>>  When a committ is vetoed, it should be reverted quickly.   Remember, a
>>>  veto is likely to come only after sufficient discussion on the list
>>>  for one or more committers to think a veto is justified.  So if there
>>>  was a just a simple misunderstanding then it would have already been
>>>  taken care of.  So when a veto comes we need to treat it seriously and
>>>  revert the change.
>>> 
>> 
>>  The thing about the veto, and this happened today, is that there must
>>  be a clear technical issue with it. We were far from that point early 
> today.
>> 
> 
> That is not for you alone to judge.  When the police pull you over and
> ask you to get out of your car, that is not a good time to argue and
> refuse to do it.  You will get your day in court.  Similarly, when you
> get two vetoes, this is not the time to argue.  Instead, revert your
> code, then argue your point.
> 
 We are talking about a innocuous change that was evaluated
in ... 3 days?.Despite the flamefest I think in 3 days too little
*real* discussion took place to raise a veto.

I said I didn't consider the vetos valid: invalid issues have no weight.

I asked who was the natural judge here, I cannot be the judge but
certainly it can't be you either. Now we know the judge is the PMC.

People have real lifes around things that are not OpenOffice. We also
know now that you should have waited around 3 days, specially since
this was not an urgent issue.

>> 
>>>  (Think of it this way:  If we treat a veto merely as "Let's 
> discuss
>>>  this some more on the list but not take any actions right now" 
> then we
>>>  don't really have a veto option. )
>>> 
>>>  If the original coder is willing and able to revert quickly, then
>>>  great.  But anyone, including the veto'er can do this.  It is not
>>>  rocket science and does not require special knowledge:
>>> 
>> 
>>  I disagree, this is extremely rude. Just like you don't put your
>>  fingers into your neighbours dish, you have to give space to other
>>  committers. Reverting someone elses commit is an insult, you are
>>  saying: you completely screwed up your change is worthless you
>>  shouldn't be a committer
>> 
> 
> The code you check in, unlike your dish, is not yours.  You don't own
> it.  You don't control it.  You should not feel insulted.

My commits are my responsibility. You found a bug? Sure.. the code
is full of them, still that is not a reason why *you* should revert it.

Also consider thinking in terms of value: for the project the code I
am working on is more valuable than the code you want to revert.

> Someone did something to code, not to you.

You were warned not to revert. You may not feel like you meant it
but what you did was deeply insulting. It is not OK.

> 
> 
>>>  svn merge -c -XXXXXX (where XXXXXX is the revision number of the
>>>  revision that introduced the change you want to revert)
>>>  svn ci
>>> 
>>>  That's it.
>>>

That's not "it": proper care has to be taken considering the work flow.

You actually did a mess: the log has no information on why
the revert was made. The bugzilla issue was not referred to, and
you reverted some header changes that you shouldn't. You obviously
had no respect for the work being done or the process being followed.

I personally cannot work like this: my work (code and time) receives
more respect in other projects.

As the result of this situation I am reevaluating my role in this project.
I currently have no space or motivation.to do real development work.

I still deeply care: This project is important and I see there is a group
of awesome people doing a great job. I still can and will help: I intend
to do important updates and platform fixes but I will likely be taking a
more passive role from now on.


Pedro.

Reply via email to