Rob, Please count how much of the emails in these inordinate threads are your emails.
Please review the following: http://openoffice.apache.org/list-conduct.html Thank you. Regards, Dave On Feb 15, 2013, at 11:21 AM, Rob Weir wrote: > 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
