[top posting] Thanks for all the help with this and for the new NONE for target release. Hopefully, it will be used sparingly assuming we us e RESOLVED-FIXED as only for issues in which an actual commit is used. Issue 126828 has now been changed to UNCONFIRMED. How to differentiate UNCONFIRMED from RESOLVED--NOT AN ISSUE will be a challenge. Hopefully, this can be clarified to our QA helpers
And, dang, one my examples was NOT a correct illustration of the problem. Too many BZ windows open yesterday I guess. Ok, back to my investigations. On 03/21/2016 12:05 PM, Dennis E. Hamilton wrote: > > >> -----Original Message----- From: Patricia Shanahan >> [mailto:p...@acm.org] Sent: Monday, March 21, 2016 >> 09:10 To: d...@openoffice.apache.org Subject: Re: Can we >> add the value "N/A" to the Target Milestone field >> >> On 3/21/2016 8:59 AM, Kay Schenk wrote: >>> On Sun, Mar 20, 2016 at 3:46 PM, Dennis E. Hamilton >> <dennis.hamil...@acm.org >>>> wrote: >>> >>>> I want to clarify this. >>>> >>>> I think the problem might be that "Resolved - >>>> Fixed" is being used incorrectly. As far as I know, >>>> there are many cases where this >> resolution >>>> is used where one of "Resolved - Not an Issue" >>>> (though not too >> often), >>>> "Resolved - Irreproducible", "Resolved - Won't >>>> Fix", or "Resolved - Obsolete" should be used. >>>> >>>> Is that what you are seeing, Kay? >>>> >>> >>> ​Well maybe so. In the past, I have used >>> RESOLVED-FIXED to determine what's been committed to >>> our source, thus leading to a Target Release. >>> Yesterday, I started going through RESOLVED-FIXED >>> items to be sure >> some of >>> these fixed issued did have a Target Release. Some of >>> these RESOLVED- >> FIXED >>> issues seem to be either user support >>> issues/questions that do not >> entail >>> source code corrections at all, or similar type >>> situations. In one of >> the >>> cases I sited above, I think the issue originator >>> marked it with RESOLVED-FIXED, and really i don't >>> know if this was the right thing to >> do >>> or not. > [orcmid] > > My impression is that original reporters rarely do this > and might not even have the necessary karma. > > As you can see in one of the two you linked to, I was the > guilty culprit [;<). > >>> >>> So, we can use the new NONE (thank you Marcus!) as >>> the Target Release, >> or >>> do something else to ignore these types of issues for >>> verification in >> a >>> build. The problem is stemming from the use of BZ as >>> both a code centric >> problem >>> reporting mechanism and a user support tool. >> >> I don't think it should be marked RESOLVED-FIXED unless >> it was actually fixed, and therefore has a release in >> which the fix first appears. To me, RESOLVED-FIXED with >> a target release of NONE is self-contradictory. >> >> What is the objection to changing the resolution to >> reflect reality? >> >> For example, if it was a user support issue that does >> not entail a source code correction, shouldn't it be >> marked RESOLVED - NOT_AN_ISSUE rather than RESOLVED - >> FIXED with a target date of NONE? > [orcmid] > > I agree that RESOLVED - FIXED might be inappropriate in > many cases. However, RESOLVED - NOT AN ISSUE is often > too heavy-handed. It can clearly be an issue to users, > especially when it is an identifiable usability matter > although not a code bug, but still there may be some > clear product-behavior deficiency. And the issue may be > recognized as such by the project, too. > > The problem is "Issue for Whom," when it is about a > deficiency in the product but not a bug in the > conventional sense. Since we our software is > user-facing, it would be good to own that such issues are > issues for us as providers of something valuable to > users. BZ is our basic mechanism for existence and > attention to such cases. > > I also recall seeing "NOT AN ISSUE" used when > IRREPRODUCIBLE might be a better matter (i.e., when the > reporter fails to provide needed details to know > specifically what the matter is). > > Also, sometimes the "fix" is elsewhere (i.e., > documentation, workarounds on a wiki, whatever). I > suppose that means CONFIRMED but not acted on until > cleared up somehow, or a WONT-FIX that indicates the > workaround is all that is coming. > > I think it comes down to specific cases. The ability to > have a RESOLVED-FIXED with a "None" release target is > useful, and we now have it available. We just need to > use it appropriately. It just means that the fix is > other than in a code release. > > We also need to make clear what the general uses of these > categories are. That may already exist somewhere but it > perhaps need to be surfaced more and promoted on the QA > and DEV lists. > >> >> Patricia >> >> >> --------------------------------------------------------------------- >> >> 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 > -- -------------------------------------------- MzK "Time spent with cats is never wasted." -- Sigmund Freud --------------------------------------------------------------------- To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
