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. 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. > >> (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. Someone did something to code, not to you. You should feel no more insulted than if I had changed some other piece of code that you also did not own and did not control. You need to separate your ego from your code. Some primitive cultures have a spiritual attachment to everything that leaves their body. They take their hair and fingernails and bury it in secret places lest their enemies find it and get power over them. We need to avoid having a similar attachment to our code. > Under no circumstance should a committer be intimidated or > made unconfortable about committing, furthermore, committing > early is good as it let's your code be tested. Of course if you are > being asked to revert all your changes you know you have to be careful. > I agree that no committer should be intimidated etc. Therefore stop feeling that you are your code, or your code is you. If you have an excessive feeling of ownership or control over the code that you contribute then you will have no end of problems. Anyone who changes your code is touching your personal belongings. Anyone who reports a bug is faulting you. Anyone who removes your code is destroying your stuff. Anyone who reuses your code is stealing. You can stop these feelings by realizing that you are not your code, and you do not control the code that you contribute to the project, and that criticism of code is not criticism of you personally. We're all working for the same things -- a quality product that the public will benefit from. Don't let your ego get in the way of working together on 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. >> > > Oh, and I would certainly expect more care when reverting if you > are not regularly working with the code: imagine trying to type a > letter in a bus while a strager is erasing what you write. > If the revert happens quickly, i.e., before other conflicting changes are made in the same files, a revert is trivial and requires no special knowledge of the code. That is one reason a revert should happen immediately after a veto -- that is the least painful time to do it. >> It is very likely that the person whose changes were vetoed will not >> like the veto or the revert. That is quite natural. > > What we have to avoid specifically are reverts to reverts: SVN is not > the place to resolve issues: the mailing list is. > Correct, but that discussion continues after the revert has occurred. The revert removes the controversial code. It does not remove the controversy. Discussion can continue, and if the vetoes are lifted then the code can be restored. > In the case of todays revert you should have waited as I could've > tried a quick fix. This is/was not an urgent issue and 99% of AOO > was fully operational without affecting anyone elses work.. > The two vetos were for the change in behavior of 0^0. The fact that your patch had several other errors in it does not make the veto any less valid. The argument of "Let's not revert until I fix some other bugs in the patch" is not a very good one, IMHO. Regards, -Rob > It doesn't really matter anymore (specially if the bug is where I > think it is) but it is an experience to learn from. > > Pedro.
