Am 03/21/2016 10:36 PM, schrieb Kay Schenk:
[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
I repeat my suggestion for another resolution status as it maybe got
lost in people's inboxes.
My suggestion is to create a RESOLVED - RESOLVED status. Maybe still to
close to RESOLVED - FIXED, but then let's see if there are better wordings.
Instead of setting to a status that doesn't make sense or to
differentiate together with another field (like the target), why not
setting an user issue that could be resolved to a status that actually
show this.
Marcus
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org
For additional commands, e-mail: qa-h...@openoffice.apache.org
