On Fri, Feb 15, 2013 at 8:28 AM, Pedro Giffuni <p...@apache.org> wrote: > > > ----- Messaggio originale ----- >> Da: Rob Weir >> On Thu, Feb 14, 2013 at 8:49 PM, Pedro Giffuni <p...@apache.org> 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. >
Actually the change you made was very controversial and you knew it. You said so in the BZ issue before you checked it in. You knew that this code had many edge cases. I mentioned this in the BZ issue before you checked in the code. In fact, the edge cases that I mentioned are the very ones you broke. Your changes were reckless. You seemed to have wanted to force a crisis here, by checking in controversial code, despite concerns that were raised before you did so, by not testing it adequately, by ignoring even the errors you saw on your own machine, by unsubscribing to the dev list to avoid discussion of the mess you made, etc. If someone wanted to cause trouble I cannot think of anything more they could have done to ensure that they would be the center of attention in a manufactured crisis. > 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. > And after you revert, if the PMC agreed that there was no technical issue behind the vetoes then the code could go back in. But it is not up to you to wait for when you think this is resolved. > 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. > Again, you stated that you would not revert the patch. I asked you a second time and you still refused. That is not a situation where waiting three days is needed. You already refused. As it is, we were very fortunate that I was able to revert at the time. Otherwise I might have been distracted by other work, and not had time to do so, or to do further testing and find the other serious flaws in your patch. It is very likely that these cases would not have been caught by QA during 4.0 testing and we would have shipped a spreadsheet with horrible flaws in it that would have brought disrepute to the project and hurt it immensely. The project was very fortunate that I was able and willing to work on this issue at that time. >>> >>>> (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. > The quality of the product is everyone's responsibility. And again, I vetoed and reverted because of the backwards compatibility issue, not because of the additional bugs you introduced. > 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. > Yes, I know you have threatened to stop coding if you do not get your way I believe you have done this on several occasions before as well. >> 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. > And you were warned about a likely veto in the BZ issue before you committed the code. That should have led you to propose the change on the dev list first, and to get consensus, before checking in the code. But instead you rammed it through over the clearly expressed concerns. And you stated you would not revert the change. And you unsubscribed to the dev list. So you did everything possible to provoke an incident. Well, you succeeded in this. >> >> >>>> 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. > The log refers the revision that was revoked. Anyone can then refer to that revision to see the BZ issue number. Regards, -Rob > 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.
