Apache OpenOffice (AOO) Bugzilla – Issue 3871
Default search criteria hides important issues at crucial times.
Last modified: 2017-05-20 09:42:51 UTC
Just before release 641d came out, I tried 641c and got bit by the "Menus don't work unless you have 'click to type' set" bug. This represented to me a very serious bug, and a show-stopper for a site-wide installation. When I went to open an issue about it, I was the good doobie and did a query to see if it was a known issue. I found issue #2943 and another issue. The other issue, I sent a comment saying it should be labeled as a dupe of 2943. I then sent an irate email to my local Sun / StarOffice contact about how so terrible a bug could have been left to languish. The Sun contact told me that the fix for that bug was, in fact, scheduled for roll-out very soon. (In fact it came out later that week in 641d.) The issue that was officially tracking the bug was issue #2691. That issue NEVER SHOWED UP in my query! If issue 2943 had been correctly labeled as a duplicate of issue 2691, I might have COMPLETELY missed the fact that this bug is known, fixed, and in-process for deployment. PLEASE find a way to show known and fixed problems in the default query until the fix makes it out into the world! Otherwise the good development work is not properly shown to people, and people waste effort logging reports for which the fix is already in progress. Having worked with Red Hat, Ximian, and Mozilla with bugzilla, I was VERY disoriented to find that the convention they used, which I got used to, that showed me what I needed to know, had not been adopted by OpenOffice.org. PLEASE fix this! I think the problem here is that "Resolved" is left out of the default bugzilla/issuezilla query, but bugs that are FIXED everywhere except at OpenOffice.org are left "Assigned". Because we think in terms of ISSUES, we change the status to "RESOLVED" when the fix is made, and the information becomes invisible, and only after contemplating the subtle clash of conventions does the reason become apparent. Suggestion: Either enable RESOLVED in the default query (easy to do) Or get people to NOT tag something as RESOLVED until it makes it out the door in an actual release. (hard because people already do something different by habit and habits are difficult t retrain.) Thanks very much for listening, -Bill Cattey MIT
accepting issue. It is a prod mgt issue for collab.net. louis
hi, support: this is a legitimate enhancement request. Please see if we can add this to the list of enhancements. thanks louis
I'm not sure I understand this Louis. When I look at the query page, the resolved option is available. Is there more to this request? Could you please elaborate as you have deemed this a "legitimate request"?
Brian: Let me try and clarify: Go to the search page, and search for a problem that is "RESOLVED" but for which the fix has not yet shipped. You have to explicitly ADD "RESOLVED" to the query. Red Hat and Ximian are examples of uses of bugzilla where the expected procedure is, "If the fix is not in the hands of users, the problem is still open, and you can find it in the default query." When people use IssueZilla, they will expect that if the problem happens to them, and the fix has not been shipped out, that they will find the problem, without having to carefully review the default search query and add "RESOLVED" to it in order to see results.
Bill - Thanks for the clarification. I now understand your concern. The present method of assigning status to issues is particular to this site. OpenOffice and Collab have come to an agreement on how to deal with issues that are fixed in versions yet to be released. Ximian and Redhat do it one way, OpenOffice does it diferently. It is very simple to set a default query in issuezilla that you are more comfortable with; you can use the radio button on the bottom of the query page "remember this as they default query" which will allow you do this. If you are asking for OpenOffice to change their policies, that is a question for Sun and should be assigned to issues@openoffice.org. This is another uniqueness of this site, issues assigned to issues@oo.o are for the OpenOffice support team, while issues assigned to support@oo.o are for the collabnet suport team.
Actually, that's where I brought this issue in the first place. Here is a copy of the response I got from the person who promised to make this an issue and direct it to where the policy change I requested could get considered. While I am grateful for the time you and others are taking to think about this and other issues, the simple fact remains: Sun and Collab have come to an agreement at odds with common practice the market leaders in free software. Since April people have been falling into a hole created by an unintended consequence of that agreement, and now all we have accomplished is to restate the argument and say it belongs with someone else. Perhaps this inability to understand is why Linux at the lead and Sun is behind in the present market? Give me the telephone number of the appropriate people in Sun and Collab and I will help them understand and remedy this problem. -wdc Date: Wed, 03 Apr 2002 17:50:11 -0800 Subject: Re: [webmasters] Re: Possible Star Office 6 show stopper. From: Louis Suarez-Potts <louis@collab.net> To: <webmasters@openoffice.org>, Bill Cattey <wdc@mit.edu>, <Sonja.Thieme@Sun.COM> CC: <pl@openoffice.org>, <apse@mit.edu> Bill, You raise a good point, of course. I have no control over it, however. You could file issue, assign it to me, and I'll forward it to the CollabNet product manager. That, believe it or not, works. Louis Suarez-Potts Community Manager on 3/26/02 9:34 AM, Bill Cattey at wdc@MIT.EDU wrote: > > > SUGGESTION to webmasters@openoffice.org: > > I understand that the default query needs to avoid displaying issues > that have been fully resolved. Unfortunately in this case, the > resolution was known, but not yet deployed. If issue 2943 had been > correctly labeled as a duplicate of issue 2691, I might have COMPLETELY > missed the fact that this bug is known, fixed, and in-process for > deployment. > > PLEASE find a way to show known and fixed problems in the default query > until the fix makes it out into the world! Otherwise the good > development work is not properly shown to people, and people waste > effort logging reports for which the fix is already in progress. > > -wdc >
Bill, the enhancement you suggest is meritorious and is now going through CN's process. This process has been revamped due to the load of enhancement requests and the desire of CN to address them (we care, honest). I've been stressing that the IZ issues--interface, and the one you mention below--are really important and need immediate attention. What does this mean? It means that in the next upgrade it stands a good chance of being resolved. Contact me directly for further updates and issues regaring IZ and how it can be improved. thanks louis
I am reassured to hear that there is a process, that the process has recently been improved, and that aligning with common practices elsewhere is an important consideration. From Brian's comments, I was worried that the issue had gone to the wrong place and that we had to begin anew. -wdc
Um... This issue is now assigned to me? I just started getting automatically generated email saying I'm going to get email once a day until I deal with this issue. I THINK someone did the wrong thing, here.
Bill, in cases like this, just reassign it back. The convention is that the person who filed it is reassigned the issue to make comments, approve plans, etc.; but then he can reassign it. taking it from you. louis
closing with a later the update planned for later this year addresses this problem -louis