On Fri, Feb 15, 2013 at 2:19 PM, Rob Weir <robw...@apache.org> wrote: > On Fri, Feb 15, 2013 at 9:40 AM, janI <j...@apache.org> wrote: >> On Feb 15, 2013 3:25 PM, "Greg Stein" <gst...@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 <robw...@apache.org> wrote: >>> > > On Fri, Feb 15, 2013 at 8:45 AM, Greg Stein <gst...@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
