On Mon, May 6, 2013 at 10:48 PM, Pedro Giffuni <p...@apache.org> wrote: > > > I don't have time for this if you really want to keep open a BZ issue for a > feature > no one is working on, I am OK with that. >
Thanks. That is exactly what I want and that is exactly how we've been using BZ for many years. That is why we have the ENHANCEMENT issue type, to track ideas that no one is working on at the moment. These ideas include many items of varying difficulty that might be appropriate for new coders. So having a relatively simple issue, with a prototype patch, is ideal for them. > I will try to avoid updating the state of my bug reports from now on to avoid > these threads that you seem to like so much. > My recommendation is for all of us to review our issue lifecycle page and see how "Won't Fix" is applied. Everything works more smoothly if we're following the same rules of the road, and using these issue dispositions to mean the same thing. http://wiki.openoffice.org/wiki/Issue_lifecycle Of course, if we want to change the process described on that page, then let's start a new thread and discuss that. Regards, -Rob > Pedro. > > > ----- Messaggio originale ----- >> Da: Rob Weir > >> >> On May 6, 2013, at 8:03 PM, Pedro Giffuni <p...@apache.org> wrote: >> >>> >>> >>> >>> >>> ----- Messaggio originale ----- >>>> Da: Rob Weir >>> ... >>>> The fact that you wrote the issue initially is not relevant to whether >>>> the issue is marked "won't fix" or not. That field is >> not for >>>> entering your personal opinion. It is for expressing the project's >>>> consensus for how the issue is handled. Of course, you are welcome to >>>> enter your personal opinion as a comment. >>> >>> It is my personal and technical opinion that it should be labelled WONT >>> FIX. If your expert opinion is different I encourage you to grab the issue >>> and *then* reopen it. If the project is really lucky you can even prove me >>> wrong ;) >>> >> >> Then I invite you to provide a technical explanation for this rather >> than the "it seems that no one is interested in this" comment that you >> gave when you closed the issue. You must agree that this was not a >> technical reason. Nor was it one when you said you closed it because >> you didn't want to receive notifications about it, nor was it a >> technical justification when you said you didn't want someone to >> accidentally commit it, nor when you suggested that you were >> withdrawing permission to use the patch. After spending much time >> reading your comments I still have no clue what exactly your technical >> concerns are. >> >> As you wrote initially in the issue, this is only a prototype. I think >> it is clear that it was not finished work. I don't think someone would >> accidentally commit it as-is. But if you think additional caveats are >> warranted then please add them as comments to the issue. That's where >> they belong. That's where they will do the most good. But if the >> reason for the issue remains valid, i.e., that Boost has faster stats >> code than what we have now, then the issue itself should remain open. >> >> Of course if you were in error in your earlier analysis, and Boost is >> not faster then by all means give that explanation and mark the issue >> as INVALID. But please don't give a comment of "no one seems >> interested" and then starting deleting stuff. What we have in BZ is >> an important record of issues and opportunities in the code and >> marking something "Won't Fix" when the underlying issue is still >> valid >> is not right. >> >> Regards, >> >> Rob >> >> >>>> >>>>> I guess will only comment on the withdrawn patch: >>>>> >>>>> The withdrawal doesn't have anything to do with how long the >>>>> patch has been available, I just don't think it should be >>>>> committed by accident. >>>>> >>>>> Last time I knew, the ASF policy is not to take anything that the >>>>> >>>>> author (me in this case) doesn't want taken so I expect if >> someone >>>>> wants it he/she can ask me about it and I may even give one or two >>>>> new hints about it :). >>>> >>>> This is true for non-committers. But committers have submitted an >>>> ICLA and have already promised, in writing, that when they offer >>>> patches that the ASF has permission to use the code. I'd recommend >>>> thinking carefully about reneging on that promise. If your issue is >>>> only whether someone commits your patch without review then I >>>> recommend that you explain that in a comment to the issue. >>> >>> The icla applies to my contributions to the project and it is perfectly >>> valid since the moment I signed it, that hasn't changed. >>> >>> Do keep in mind that if I had thought it was a good idea to commit >>> the patch I would have just done it, like I did with so many patches >>> before. >>> >>> After thinking about it for a while I think I was right not to commit it >>> in the first place. I still think the issue should be labelled WONT FIX. >>> >>> The patch is withdrawn for good reasons but if you want to spend time >>> on it be my guest, and yes the project has permission to use my patch >>> under ALv2. >>> >>> Pedro. >>> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
