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. -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
