On Tue, May 7, 2013 at 7:45 AM, janI <j...@apache.org> wrote: > On 7 May 2013 12:43, Rob Weir <robw...@apache.org> wrote: > >> On Tue, May 7, 2013 at 3:14 AM, janI <j...@apache.org> wrote: >> > Hi >> > >> > I have now read this thread twice, and see a to me well known pattern. >> > >> >> But have you read the history of the BZ issue? >> > yes > >> >> > @pedro, I do agree with rob, that you might have choosen your comment >> more >> > wisely, that said you are the expert on the subject, so if you change the >> > status to "WONTFIX" it is a complely correct action. The issue is still >> > seachable in the database, but you signal to everybody this will not be >> > fixed (some day in future, somebody might solve a similar issue). I do >> > exactly the same with the fields (mwiki) where I feel confident, and only >> > asks for others opinion if I am in doubt. >> > >> >> 1. No one in their right mind searches for issues marked "WONTFIX". >> That is where we hide issues that no one should work on. For example, >> if some functionality is odd but it is needed for standards >> compatibility or for backwards compatibility we mark it WONTFIX to >> signify that the issue is real but there are important reasons why the >> functionality cannot be changed. It does not mean that Committer X >> will not fix it. Remember, the issue was entered with an explicit >> statement that Pedro was not going to work on it. So it is incorrect >> to say that the issue is in any sense findable once it is marked >> WONTFIX. >> > > > >> >> > I hope you will reconsider, this list and community is not (yet) >> completely >> > dominated by the opinion of any single person, but if everybody withdraws >> > when being lectured, it soon will be. We badly need motivated, critical >> > members. >> > >> > @rob, please dont misunderstand me, I respect you for the awfull amount >> of >> > positive work you do for AOO, but I hope you will consider (no need to >> > reply to my mail just in private), which of the following 2 options you >> > think are the better option for our community: >> > >> > a) we allow bullying/lecturing our fellow committers, causing the >> committer >> > to withdraw and the community in praxis looses a motivated committer. >> > >> > b) we accept the expert choise of our fellow committers, even though we >> > personally might not agree, and keep a motivated committer that works >> > actively. >> > >> >> If you the BZ history you would have seen that I reopened the BZ after >> Pedro closed it, and I gave a detailed justification why. Pedro then >> immediately re-closed it. Where is my expert opinion considered here? >> Remember, I am the one who set up the "easy fixes' mechanism in BZ so >> new coders have some tasks to work on. So that task depends on >> curating a set of BZ issues that are meaningful but no one was working >> on. In my expert opinion this could be one such task. So why are you >> denying me my opinion? >> > > I am in no way denying you having on opinion, on the contrary I think it > is good to have opions....I just believe we should all be able to air our > opinions and have our views, with respect for each other. And if I may add > I feel (now being one myself) the PMC group have an extra obligation to > restrain ourself, and give others quite some leeway. > > Mail "wars" are not positive for the community, indepent of who is > right....they are much more destructive than the subject itself. Bascially > we can all stop such a "war" typically by stopping and thinking...is this > issue really so important to the community. > > >> >> Pedro's concerns can easily be met by adding an informative comment. >> Mine cannot be met in any way by burying the issue as "Won't Fix" >> > > > I have put several mwiki bugs on WONTFIX (in accordance with the lifecycle > definition), one example "cleanup japanese mwiki", I commented the bug > waited 72 hours, no one responded...so I changed state to "WONTFIX", this > is however for sure one of your easy tasks for a japanese volunteer. > > If we are not allowed to put issues to WONTFIX, then we for another > status, like WILLNOTBEFIXEDBYTHECURRENTAVIA > BLEEXPERTS or POTENTIALCANDIDATEFORANEWPERSON. When I work with BZ I want > to see the active bugs I can do with (inside my "responsibility" field) and > not a lot of noise. >
Unfortunately that is not how Bugzilla works. In issue has one status and one status only and we cannot assign a special status to a bug so that it is not visible to only for you or only for Pedro. The process for marking something "Won't fix" is documented on the wiki: "In case of a feature request: If you think, it should not be implemented, discuss this on the mailing list and if your opinion gets consensus, set the status to RESOLVED with reason WONTFIX. Explain the reason in the comment and put the link to the discussion in field URL. Close the issue. " http://wiki.openoffice.org/wiki/Issue_lifecycle Pedro did not follow the process. He didn't bring it to the list and he never gave a explanation. I helped Pedro approach closer to the process by bringing the issue to the mailing list. And I stated good reasons (IMHO) why the issue should remain open. I disagree with you that we should disregard the issue resolution process issues in BZ merely to appease egos in this project. That approach is doomed to fail since there is more than one ego in the project and there will always be disagreements. The process defines how these differences of opinions are resolved, namely by seeking consensus here on the list. -Rob > >> >> As soon as it was evident that Pedro was engaging in an editing war in >> BZ I brought the issue here to the dev list. That was the proper >> thing to do. >> > > Correct no doubt about it...that is one of the purposes of the list. But > remembering the situation we as a community are in, our words should be > choosen carefully....in general we should try to motivate people to do the > right thing by being positive and open. > > > >> >> > I have no doubt that I prefer b), it really doesnt matter if a database >> > field is set to WONTFIX, it stayes searchable, compared to having somone >> > actively working on making AOO a better product and community. >> > >> >> Is this really and either/or thing? >> > > Nice play with words...of course it is not. But fact is we want our > community to grow, and in order to that, everybody need to feel its fun > being here. > > Putting a couple of issues on WONTFIX, by a specialist in the area is not a > concern I have, pr definition I trust my fellow committers and their > judgment. > > For new coders (C++, make etc.) we have more than enough tasks, if you come > with the C++ coders, I promise within 24 hours to supply them with tasks in > l10ntools (they are not entered in BZ, because next week I have worked some > more, and have other small projects). Our main problem is not the "WONTFIX" > it is a lot more that we do not attract C++ coders, and being one myself I > have an idea why that is, but that is another theme. > >> >> > During my time in AOO, we have added 3 committers and by using a) and 2 >> > have at least reduced their work heavely. >> > >> > I do believe we all try to do our best in our own way, but lets please >> use >> > the energy to make a better product, not to fight each other. >> > >> >> So are you saying that closing BZ issues with the sole comment "There >> seems to be little interest in this" is "actively working on making >> AOO a better product and community?" Really? What about someone who >> then reopens the issue because it is a legitimate issue that could be >> a good candidate for a new coder? Is that then, in your book, >> working against the community? And then what about the person who >> immediately re-closes the issue without discussion? >> > > No, I actually wrote in the top, that I agree with you, pedros comment was > not correct (I also agree that he could in general use a more postive > language). > > I take your word for that this issue is good for a new coder....and at the > same time I am disapointed with myself, because I cannot climb the ladder > you set for new coders. I would not take that issue with my current > knowledge, that I thought was levels away from being a new coder. > > A member of our community disapointed is a lost hand (or part of), while a > member being motivated can work wonders. Let Pedro (and me) have his > WONTFIX, and challenge us all instead to make new issues...just remember > one thing, when people like me take time to enter issues, I would be > disapointed if there are no one around to catch any of the issues. > > I am not trying to start a new long discussion, the only reason I responded > to the thread was because I felt a deja vue from earlier threads where I > was involved...I highly agree with your intentions, but please lets stop > word hacking...and do some real hacking instead !!!! > > have a nice day. > jan I. > > >> Regards, >> >> -Rob >> >> > this just being my 2cent. >> > >> > Jan I. >> > >> > >> > >> > On 7 May 2013 04:48, 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. >> >> >> >> 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. >> >> >> >> 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 >> >> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org >> For additional commands, e-mail: dev-h...@openoffice.apache.org >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
