You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by Kay Schenk <ka...@gmail.com> on 2016/03/20 21:08:05 UTC
Can we add the value "N/A" to the Target Milestone field
To our BZ admins.
We seem to have a number of issues in BZ that are now listed
as Resolved/Fixed but don't seem to pertain to an actual
upcoming release.
Examples:
https://bz.apache.org/ooo/show_bug.cgi?id=126652
https://bz.apache.org/ooo/show_bug.cgi?id=126828
Can we add something like "N/A" or the like to our Target
Milestone field rather than the default "--" so we know
these should never be considered for a release?
Thanks.
--
--------------------------------------------
MzK
"Time spent with cats is never wasted."
-- Sigmund Freud
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
RE: Can we add the value "N/A" to the Target Milestone field
Posted by "Dennis E. Hamilton" <de...@acm.org>.
Thanks for the "None" Target, Marcus.
> -----Original Message-----
> From: Marcus [mailto:marcus.mail@wtnet.de]
> Sent: Sunday, March 20, 2016 15:38
> To: dev@openoffice.apache.org
> Cc: qa@openoffice.apache.org
> Subject: Re: Can we add the value "N/A" to the Target Milestone field
>
> Am 03/20/2016 09:08 PM, schrieb Kay Schenk:
> > We seem to have a number of issues in BZ that are now listed
> > as Resolved/Fixed but don't seem to pertain to an actual
> > upcoming release.
> >
> > Examples:
> > https://bz.apache.org/ooo/show_bug.cgi?id=126652
> > https://bz.apache.org/ooo/show_bug.cgi?id=126828
> >
> > Can we add something like "N/A" or the like to our Target
> > Milestone field rather than the default "--" so we know
> > these should never be considered for a release?
>
> sounds reasonable. I've added an "None" to the list of available
> milestones for many products (the application modules and related
> things).
>
> Marcus
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: qa-help@openoffice.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
For additional commands, e-mail: qa-help@openoffice.apache.org
RE: Can we add the value "N/A" to the Target Milestone field
Posted by "Dennis E. Hamilton" <de...@acm.org>.
Thanks for the "None" Target, Marcus.
> -----Original Message-----
> From: Marcus [mailto:marcus.mail@wtnet.de]
> Sent: Sunday, March 20, 2016 15:38
> To: dev@openoffice.apache.org
> Cc: qa@openoffice.apache.org
> Subject: Re: Can we add the value "N/A" to the Target Milestone field
>
> Am 03/20/2016 09:08 PM, schrieb Kay Schenk:
> > We seem to have a number of issues in BZ that are now listed
> > as Resolved/Fixed but don't seem to pertain to an actual
> > upcoming release.
> >
> > Examples:
> > https://bz.apache.org/ooo/show_bug.cgi?id=126652
> > https://bz.apache.org/ooo/show_bug.cgi?id=126828
> >
> > Can we add something like "N/A" or the like to our Target
> > Milestone field rather than the default "--" so we know
> > these should never be considered for a release?
>
> sounds reasonable. I've added an "None" to the list of available
> milestones for many products (the application modules and related
> things).
>
> Marcus
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: qa-help@openoffice.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Can we add the value "N/A" to the Target Milestone field
Posted by Marcus <ma...@wtnet.de>.
Am 03/20/2016 09:08 PM, schrieb Kay Schenk:
> We seem to have a number of issues in BZ that are now listed
> as Resolved/Fixed but don't seem to pertain to an actual
> upcoming release.
>
> Examples:
> https://bz.apache.org/ooo/show_bug.cgi?id=126652
> https://bz.apache.org/ooo/show_bug.cgi?id=126828
>
> Can we add something like "N/A" or the like to our Target
> Milestone field rather than the default "--" so we know
> these should never be considered for a release?
sounds reasonable. I've added an "None" to the list of available
milestones for many products (the application modules and related things).
Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
For additional commands, e-mail: qa-help@openoffice.apache.org
Re: Can we add the value "N/A" to the Target Milestone field
Posted by Marcus <ma...@wtnet.de>.
Am 03/21/2016 04:59 PM, schrieb Kay Schenk:
> On Sun, Mar 20, 2016 at 3:46 PM, Dennis E. Hamilton<dennis.hamilton@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.
We can think about an own resolution status for issues that were solved
but *not* in the code.
Example:
RESOLVED - RESOLVED
> 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.
This wouldn't be a bigger problem when we would be more consequent and
do not use BZ as a support tool (e.g., verifing documents if they are
really broken). The better way would be to point these people to the
support forums - also because there are much more poeople that could
help with tips and action.
But I also know it's difficult to enfource this way. ;-)
Marcus
>>> -----Original Message-----
>>> From: Andrea Pescetti [mailto:pescetti@apache.org]
>>> Sent: Sunday, March 20, 2016 14:09
>>> To: qa@openoffice.apache.org; dev@openoffice.apache.org
>>> Subject: Re: Can we add the value "N/A" to the Target Milestone field
>>>
>>> Kay Schenk wrote:
>>>> We seem to have a number of issues in BZ that are now listed
>>>> as Resolved/Fixed but don't seem to pertain to an actual
>>>> upcoming release.
>>>
>>> Everything that was marked RESOLVED FIXED will be in 4.2.0. So 4.2.0 is
>>> a perfectly valid value for these cases.
>>>
>>> Just to be clear: 4.1.2 was a maintenance release and issues had to be
>>> approved as release blockers in that case. 4.2.0 will be a normal
>>> release, made from trunk, so everything that is on trunk (untile a
>>> certain moment when we will decide to branch) will be into it
>>> automatically. So the target is 4.2.0 in those cases.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Can we add the value "N/A" to the Target Milestone field
Posted by Marcus <ma...@wtnet.de>.
Am 03/22/2016 12:52 AM, schrieb Pedro Lino:
>> It's not about to draw the line between issues that are resolved and
>> verified solutions. It's about to differentiate issues that are in the real
>> application and therefore need to be fixed in the source code. Here we use
>> (or better should use) RESOLVED - FIXED.
>>
>> But what about issues that are also reporting a problem but the solution
>> (if there is any) is somewhere else? RESOLVED - FIXED doesn't fit, RESOLVED
>> - NOT_AN_ISSUE also not.
>>
>
> Why not use the same nomenclature as the "sibling project"? RESOLVED -
> NOTOURBUG
in general it's OK to look for other projects how they handle such
problems. But NOTOURBUG sounds really ignorant and a bit offensive - at
east in my ears. When I think about the users that reporting such issues
and mostly they think it's important because they cannot go on with
their work, then they deserve a more meaningful status name.
Dennis has made a good suggestion where I'll go on with answering.
> I believe Apache QA needs a flowchart such as
> https://wiki.documentfoundation.org/images/c/c4/Unconfirmed_Bugs_Status_Flowchart_Version_0.1.pdf
> https://wiki.documentfoundation.org/images/c/cb/Unconfirmed_Bugs_Status_Flowchart.odg
I'm pretty sure we have a similar flow chart somewhere in the depths of
our Wiki. But yes, in general this would help to understand how the
issue statuses are working together.
Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
For additional commands, e-mail: qa-help@openoffice.apache.org
Re: Can we add the value "N/A" to the Target Milestone field
Posted by Marcus <ma...@wtnet.de>.
Am 03/22/2016 10:04 PM, schrieb Kay Schenk:
> On 03/22/2016 09:37 AM, Marcus wrote:
>> Am 03/22/2016 04:48 PM, schrieb Dennis E. Hamilton:
>>> Many interesting ideas, ...
>>>
>>>> -----Original Message-----
>>>> From: Carl Marcum [mailto:cmarcum@apache.org]
>>>> Sent: Tuesday, March 22, 2016 03:35
>>>> To: dev@openoffice.apache.org
>>>> Subject: Re: Can we add the value "N/A" to the Target
>>>> Milestone field
>>>>
>>>> On 03/22/2016 05:02 AM, Marcus wrote:
>>>>> Am 03/22/2016 10:00 AM, schrieb Marcus:
>>> [ ,,, ]
>>>>>> [ ... ] what about RESOLVED -
>>>> MANAGED?
>>>>>> This word is maybe better known in the world. This term
>>>>>> shows that
>>>> the
>>>>>> issue has some work in it and was tackled. With a
>>>>>> closing comment you
>>>>>> can see where and why it was successful managed
>>>>>> (resolved).
>>>>>
>>>>> from Jira I also know that RESOLVED - DONE is a common
>>>>> way to say that
>>>>> an issue was successfully resolved.
>>>>>
>>>>> Marcus
>>>>>
>>>> Having a RESOLVED - DONE would be especially good for
>>>> tasks also.
>>>>
>>> [orcmid]
>>>
>>> MANAGED is interesting because of its flexibility. How it
>>> was managed should be accounted for in the commentary.
>>
>> ACK
>>
>>> DONE does seem to apply to Tasks and Enhancement requests.
>>
>> Right, and user requests are very often nothing else (e.g.,
>> "my document is broken, how to repair it?").
>>
>>> DECLINED also seems to apply to both Tasks and
>>> Enhancements. It is also a counterpart to ACCEPTED in
>>> those cases.
>>
>> Yes, it doesn't indicate that there is a solution/workaround
>> available.
>>
>> @all:
>> It seems we could have a consensus in creating a new MANAGED
>> or DONE status to set when issues are no real code problems,
>> but more user-oriented. Finally, they were solved for the
>> user's satisfaction (e.g., provided how-to's or repaired
>> documents, etc.). However, no fix in the source code has
>> been done.
>
> I would prefer DONE. MANAGED seems too nebulous to me.
> I am also assuming that once RESOLVED-DONE is set, the issue
> can be formally closed(?)
yes, that was my idea for the status and its name as this is the main
purpose for it. That's what I understood from the start of this discussion.
> This has been a really good discussion by the way.
Thanks :-)
I'm confident that we can come to a consensus. Maybe until Easter? Let's
see.
Marcus
>>> At qa@ Pedro Lino made some useful observations about how
>>> terms impact reporters and observers of the Bugzilla
>>> activity.
>>>
>>> In respect to that, I have been using WONTFIX as a way to
>>> indicate that we have no capacity to do anything about an
>>> issue, especially a longstanding one. This is primarily a
>>> way of discouraging non-project commenters arguing among
>>> themselves and to also indicate that the issue is
>>> understood, recognized, and continued lobbying is not
>>> useful. I think DECLINED may be useful in some of those
>>> cases, but WONTFIX is more truthful when the project
>>> doesn't have a way to do anything. NOTFIXING is closer to
>>> the reality. (CANTFIX would also indicate that the
>>> problem is not with the issue, but with project capability
>>> at this time.) The door is not closed completely, but it
>>> is not clear when the door will ever be opened.
>>>
>>> I agree that we do need a diagram and a description of the
>>> general application of Bugzilla categories and resolution
>>> cases. We might also need to revisit how the search
>>> defaults work with respect to the various categories.
>>> This seems like a good Wiki [update] effort. We also
>>> don't want to split things into so many categories that
>>> application and understanding becomes more difficult.
>>
>> After we have an agreement I can take over this task to grep
>> the data in Wiki to consolidate and update them with the new
>> information.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Can we add the value "N/A" to the Target Milestone field
Posted by Kay Schenk <ka...@gmail.com>.
On 03/22/2016 09:37 AM, Marcus wrote:
> Am 03/22/2016 04:48 PM, schrieb Dennis E. Hamilton:
>> Many interesting ideas, ...
>>
>>> -----Original Message-----
>>> From: Carl Marcum [mailto:cmarcum@apache.org]
>>> Sent: Tuesday, March 22, 2016 03:35
>>> To: dev@openoffice.apache.org
>>> Subject: Re: Can we add the value "N/A" to the Target
>>> Milestone field
>>>
>>> On 03/22/2016 05:02 AM, Marcus wrote:
>>>> Am 03/22/2016 10:00 AM, schrieb Marcus:
>> [ ,,, ]
>>>>> [ ... ] what about RESOLVED -
>>> MANAGED?
>>>>> This word is maybe better known in the world. This term
>>>>> shows that
>>> the
>>>>> issue has some work in it and was tackled. With a
>>>>> closing comment you
>>>>> can see where and why it was successful managed
>>>>> (resolved).
>>>>
>>>> from Jira I also know that RESOLVED - DONE is a common
>>>> way to say that
>>>> an issue was successfully resolved.
>>>>
>>>> Marcus
>>>>
>>> Having a RESOLVED - DONE would be especially good for
>>> tasks also.
>>>
>> [orcmid]
>>
>> MANAGED is interesting because of its flexibility. How it
>> was managed should be accounted for in the commentary.
>
> ACK
>
>> DONE does seem to apply to Tasks and Enhancement requests.
>
> Right, and user requests are very often nothing else (e.g.,
> "my document is broken, how to repair it?").
>
>> DECLINED also seems to apply to both Tasks and
>> Enhancements. It is also a counterpart to ACCEPTED in
>> those cases.
>
> Yes, it doesn't indicate that there is a solution/workaround
> available.
>
> @all:
> It seems we could have a consensus in creating a new MANAGED
> or DONE status to set when issues are no real code problems,
> but more user-oriented. Finally, they were solved for the
> user's satisfaction (e.g., provided how-to's or repaired
> documents, etc.). However, no fix in the source code has
> been done.
I would prefer DONE. MANAGED seems too nebulous to me.
I am also assuming that once RESOLVED-DONE is set, the issue
can be formally closed(?)
This has been a really good discussion by the way.
>
>> At qa@ Pedro Lino made some useful observations about how
>> terms impact reporters and observers of the Bugzilla
>> activity.
>>
>> In respect to that, I have been using WONTFIX as a way to
>> indicate that we have no capacity to do anything about an
>> issue, especially a longstanding one. This is primarily a
>> way of discouraging non-project commenters arguing among
>> themselves and to also indicate that the issue is
>> understood, recognized, and continued lobbying is not
>> useful. I think DECLINED may be useful in some of those
>> cases, but WONTFIX is more truthful when the project
>> doesn't have a way to do anything. NOTFIXING is closer to
>> the reality. (CANTFIX would also indicate that the
>> problem is not with the issue, but with project capability
>> at this time.) The door is not closed completely, but it
>> is not clear when the door will ever be opened.
>>
>> I agree that we do need a diagram and a description of the
>> general application of Bugzilla categories and resolution
>> cases. We might also need to revisit how the search
>> defaults work with respect to the various categories.
>> This seems like a good Wiki [update] effort. We also
>> don't want to split things into so many categories that
>> application and understanding becomes more difficult.
>
> After we have an agreement I can take over this task to grep
> the data in Wiki to consolidate and update them with the new
> information.
>
> Marcus
>
>
--
--------------------------------------------
MzK
"Time spent with cats is never wasted."
-- Sigmund Freud
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Can we add the value "N/A" to the Target Milestone field
Posted by Kay Schenk <ka...@gmail.com>.
On Thu, Mar 31, 2016 at 7:51 AM, Marcus <ma...@wtnet.de> wrote:
> [Top-Posting]
>
> OK, as there were no further comments and no real disagree I'll create a
> new RESOLVED - NOCODEFIX resolution status. This status should be set when
> an issue was solved with no change in the source code (e.g., user requests
> or how-to questions).
>
> For every fix that touches the source code please use as always the
> RESOLVED - FIXED resolution status.
>
> Marcus
SUPER!
>
>
>
>
> Am 03/26/2016 10:58 AM, schrieb Marcus:
>
>> Am 03/26/2016 10:50 AM, schrieb Andrea Pescetti:
>>
>>> Marcus wrote:
>>>
>>>> Am 03/26/2016 12:13 AM, schrieb Andrea Pescetti:
>>>>
>>>>> If the aim is to create less confusion, all proposals I've seen have
>>>>> the
>>>>> result of bringing more confusion! So:
>>>>>
>>>> I don't see why this brings more confusion. It's the opposite, one
>>>> status for "resolved with a code fix" and the other for "resolved
>>>> somehow else".
>>>>
>>>
>>> It brings more confusion since it would need to be explained explicitly
>>> (because DONE or MANAGED would apply, looking purely at their meaning,
>>> to a code fix too, and it's only a convention that we use them for
>>> "no-code" fixes only).
>>>
>>
>> maybe, but the whole BZ can be confusing - especially for normal users.
>> ;-)
>>
>> > And if we have more intuitive options I feel this would be better.
>>
>> Do you have any idea in mind?
>>
>> It doesn't have to be "NOCODE", but it should be
>>>>> something that means "nothing to do with code", and DONE does not
>>>>> really
>>>>> convey the right meaning here.
>>>>>
>>>> Then NOCODEFIX sounds more concrete.
>>>>
>>>
>>> Yes, NOCODEFIX sounds good too. Again, so long as it is a word that a
>>> developer cannot be mistaken into choosing instead of FIXED, it will be
>>> OK for me. What we want to avoid is that a developer accidentally uses
>>> DONE for a code fix and the issue is suddenly not listed in QA and
>>> similar.
>>>
>>
>> I got the idea to rename FIXED into FIXEDINCODE. Unfortunatelly, it's a
>> default and therefore a non-changeable name. :-(
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: qa-help@openoffice.apache.org
>
>
--
----------------------------------------------------------------------
MzK
"Time spent with cats is never wasted."
-- Sigmund Freud
Re: Can we add the value "N/A" to the Target Milestone field
Posted by Marcus <ma...@wtnet.de>.
Am 03/31/2016 07:40 PM, schrieb Andrea Pescetti:
> Marcus wrote:
>> OK, as there were no further comments and no real disagree I'll create a
>> new RESOLVED - NOCODEFIX resolution status. This status should be set
>> when an issue was solved with no change in the source code (e.g., user
>> requests or how-to questions).
>
> What's the maximum length? Maybe FIXED_WITHOUT_CODE is even more
> intuitive (but OK for me with the other option too!).
I've created both and got no problem or error message.
OK, you won ;- ) : New status is FIXED_WITHOUT_CODE.
Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
For additional commands, e-mail: qa-help@openoffice.apache.org
Re: Can we add the value "N/A" to the Target Milestone field
Posted by Marcus <ma...@wtnet.de>.
Am 03/31/2016 07:40 PM, schrieb Andrea Pescetti:
> Marcus wrote:
>> OK, as there were no further comments and no real disagree I'll create a
>> new RESOLVED - NOCODEFIX resolution status. This status should be set
>> when an issue was solved with no change in the source code (e.g., user
>> requests or how-to questions).
>
> What's the maximum length? Maybe FIXED_WITHOUT_CODE is even more
> intuitive (but OK for me with the other option too!).
I've created both and got no problem or error message.
OK, you won ;- ) : New status is FIXED_WITHOUT_CODE.
Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Can we add the value "N/A" to the Target Milestone field
Posted by Andrea Pescetti <pe...@apache.org>.
Marcus wrote:
> OK, as there were no further comments and no real disagree I'll create a
> new RESOLVED - NOCODEFIX resolution status. This status should be set
> when an issue was solved with no change in the source code (e.g., user
> requests or how-to questions).
What's the maximum length? Maybe FIXED_WITHOUT_CODE is even more
intuitive (but OK for me with the other option too!).
Regards,
Andrea.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Can we add the value "N/A" to the Target Milestone field
Posted by Kay Schenk <ka...@gmail.com>.
On Thu, Mar 31, 2016 at 7:51 AM, Marcus <ma...@wtnet.de> wrote:
> [Top-Posting]
>
> OK, as there were no further comments and no real disagree I'll create a
> new RESOLVED - NOCODEFIX resolution status. This status should be set when
> an issue was solved with no change in the source code (e.g., user requests
> or how-to questions).
>
> For every fix that touches the source code please use as always the
> RESOLVED - FIXED resolution status.
>
> Marcus
SUPER!
>
>
>
>
> Am 03/26/2016 10:58 AM, schrieb Marcus:
>
>> Am 03/26/2016 10:50 AM, schrieb Andrea Pescetti:
>>
>>> Marcus wrote:
>>>
>>>> Am 03/26/2016 12:13 AM, schrieb Andrea Pescetti:
>>>>
>>>>> If the aim is to create less confusion, all proposals I've seen have
>>>>> the
>>>>> result of bringing more confusion! So:
>>>>>
>>>> I don't see why this brings more confusion. It's the opposite, one
>>>> status for "resolved with a code fix" and the other for "resolved
>>>> somehow else".
>>>>
>>>
>>> It brings more confusion since it would need to be explained explicitly
>>> (because DONE or MANAGED would apply, looking purely at their meaning,
>>> to a code fix too, and it's only a convention that we use them for
>>> "no-code" fixes only).
>>>
>>
>> maybe, but the whole BZ can be confusing - especially for normal users.
>> ;-)
>>
>> > And if we have more intuitive options I feel this would be better.
>>
>> Do you have any idea in mind?
>>
>> It doesn't have to be "NOCODE", but it should be
>>>>> something that means "nothing to do with code", and DONE does not
>>>>> really
>>>>> convey the right meaning here.
>>>>>
>>>> Then NOCODEFIX sounds more concrete.
>>>>
>>>
>>> Yes, NOCODEFIX sounds good too. Again, so long as it is a word that a
>>> developer cannot be mistaken into choosing instead of FIXED, it will be
>>> OK for me. What we want to avoid is that a developer accidentally uses
>>> DONE for a code fix and the issue is suddenly not listed in QA and
>>> similar.
>>>
>>
>> I got the idea to rename FIXED into FIXEDINCODE. Unfortunatelly, it's a
>> default and therefore a non-changeable name. :-(
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: qa-help@openoffice.apache.org
>
>
--
----------------------------------------------------------------------
MzK
"Time spent with cats is never wasted."
-- Sigmund Freud
Re: Can we add the value "N/A" to the Target Milestone field
Posted by Andrea Pescetti <pe...@apache.org>.
Marcus wrote:
> OK, as there were no further comments and no real disagree I'll create a
> new RESOLVED - NOCODEFIX resolution status. This status should be set
> when an issue was solved with no change in the source code (e.g., user
> requests or how-to questions).
What's the maximum length? Maybe FIXED_WITHOUT_CODE is even more
intuitive (but OK for me with the other option too!).
Regards,
Andrea.
---------------------------------------------------------------------
To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
For additional commands, e-mail: qa-help@openoffice.apache.org
Re: Can we add the value "N/A" to the Target Milestone field
Posted by Marcus <ma...@wtnet.de>.
[Top-Posting]
OK, as there were no further comments and no real disagree I'll create a
new RESOLVED - NOCODEFIX resolution status. This status should be set
when an issue was solved with no change in the source code (e.g., user
requests or how-to questions).
For every fix that touches the source code please use as always the
RESOLVED - FIXED resolution status.
Marcus
Am 03/26/2016 10:58 AM, schrieb Marcus:
> Am 03/26/2016 10:50 AM, schrieb Andrea Pescetti:
>> Marcus wrote:
>>> Am 03/26/2016 12:13 AM, schrieb Andrea Pescetti:
>>>> If the aim is to create less confusion, all proposals I've seen have
>>>> the
>>>> result of bringing more confusion! So:
>>> I don't see why this brings more confusion. It's the opposite, one
>>> status for "resolved with a code fix" and the other for "resolved
>>> somehow else".
>>
>> It brings more confusion since it would need to be explained explicitly
>> (because DONE or MANAGED would apply, looking purely at their meaning,
>> to a code fix too, and it's only a convention that we use them for
>> "no-code" fixes only).
>
> maybe, but the whole BZ can be confusing - especially for normal users. ;-)
>
> > And if we have more intuitive options I feel this would be better.
>
> Do you have any idea in mind?
>
>>>> It doesn't have to be "NOCODE", but it should be
>>>> something that means "nothing to do with code", and DONE does not
>>>> really
>>>> convey the right meaning here.
>>> Then NOCODEFIX sounds more concrete.
>>
>> Yes, NOCODEFIX sounds good too. Again, so long as it is a word that a
>> developer cannot be mistaken into choosing instead of FIXED, it will be
>> OK for me. What we want to avoid is that a developer accidentally uses
>> DONE for a code fix and the issue is suddenly not listed in QA and
>> similar.
>
> I got the idea to rename FIXED into FIXEDINCODE. Unfortunatelly, it's a
> default and therefore a non-changeable name. :-(
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Can we add the value "N/A" to the Target Milestone field
Posted by Marcus <ma...@wtnet.de>.
[Top-Posting]
OK, as there were no further comments and no real disagree I'll create a
new RESOLVED - NOCODEFIX resolution status. This status should be set
when an issue was solved with no change in the source code (e.g., user
requests or how-to questions).
For every fix that touches the source code please use as always the
RESOLVED - FIXED resolution status.
Marcus
Am 03/26/2016 10:58 AM, schrieb Marcus:
> Am 03/26/2016 10:50 AM, schrieb Andrea Pescetti:
>> Marcus wrote:
>>> Am 03/26/2016 12:13 AM, schrieb Andrea Pescetti:
>>>> If the aim is to create less confusion, all proposals I've seen have
>>>> the
>>>> result of bringing more confusion! So:
>>> I don't see why this brings more confusion. It's the opposite, one
>>> status for "resolved with a code fix" and the other for "resolved
>>> somehow else".
>>
>> It brings more confusion since it would need to be explained explicitly
>> (because DONE or MANAGED would apply, looking purely at their meaning,
>> to a code fix too, and it's only a convention that we use them for
>> "no-code" fixes only).
>
> maybe, but the whole BZ can be confusing - especially for normal users. ;-)
>
> > And if we have more intuitive options I feel this would be better.
>
> Do you have any idea in mind?
>
>>>> It doesn't have to be "NOCODE", but it should be
>>>> something that means "nothing to do with code", and DONE does not
>>>> really
>>>> convey the right meaning here.
>>> Then NOCODEFIX sounds more concrete.
>>
>> Yes, NOCODEFIX sounds good too. Again, so long as it is a word that a
>> developer cannot be mistaken into choosing instead of FIXED, it will be
>> OK for me. What we want to avoid is that a developer accidentally uses
>> DONE for a code fix and the issue is suddenly not listed in QA and
>> similar.
>
> I got the idea to rename FIXED into FIXEDINCODE. Unfortunatelly, it's a
> default and therefore a non-changeable name. :-(
---------------------------------------------------------------------
To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
For additional commands, e-mail: qa-help@openoffice.apache.org
Re: Can we add the value "N/A" to the Target Milestone field
Posted by Marcus <ma...@wtnet.de>.
Am 03/26/2016 10:50 AM, schrieb Andrea Pescetti:
> Marcus wrote:
>> Am 03/26/2016 12:13 AM, schrieb Andrea Pescetti:
>>> If the aim is to create less confusion, all proposals I've seen have the
>>> result of bringing more confusion! So:
>> I don't see why this brings more confusion. It's the opposite, one
>> status for "resolved with a code fix" and the other for "resolved
>> somehow else".
>
> It brings more confusion since it would need to be explained explicitly
> (because DONE or MANAGED would apply, looking purely at their meaning,
> to a code fix too, and it's only a convention that we use them for
> "no-code" fixes only).
maybe, but the whole BZ can be confusing - especially for normal users. ;-)
> And if we have more intuitive options I feel this would be better.
Do you have any idea in mind?
>>> It doesn't have to be "NOCODE", but it should be
>>> something that means "nothing to do with code", and DONE does not really
>>> convey the right meaning here.
>> Then NOCODEFIX sounds more concrete.
>
> Yes, NOCODEFIX sounds good too. Again, so long as it is a word that a
> developer cannot be mistaken into choosing instead of FIXED, it will be
> OK for me. What we want to avoid is that a developer accidentally uses
> DONE for a code fix and the issue is suddenly not listed in QA and similar.
I got the idea to rename FIXED into FIXEDINCODE. Unfortunatelly, it's a
default and therefore a non-changeable name. :-(
Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Can we add the value "N/A" to the Target Milestone field
Posted by Andrea Pescetti <pe...@apache.org>.
Marcus wrote:
> Am 03/26/2016 12:13 AM, schrieb Andrea Pescetti:
>> If the aim is to create less confusion, all proposals I've seen have the
>> result of bringing more confusion! So:
> I don't see why this brings more confusion. It's the opposite, one
> status for "resolved with a code fix" and the other for "resolved
> somehow else".
It brings more confusion since it would need to be explained explicitly
(because DONE or MANAGED would apply, looking purely at their meaning,
to a code fix too, and it's only a convention that we use them for
"no-code" fixes only). And if we have more intuitive options I feel this
would be better.
>> It doesn't have to be "NOCODE", but it should be
>> something that means "nothing to do with code", and DONE does not really
>> convey the right meaning here.
> Then NOCODEFIX sounds more concrete.
Yes, NOCODEFIX sounds good too. Again, so long as it is a word that a
developer cannot be mistaken into choosing instead of FIXED, it will be
OK for me. What we want to avoid is that a developer accidentally uses
DONE for a code fix and the issue is suddenly not listed in QA and similar.
Regards,
Andrea.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Can we add the value "N/A" to the Target Milestone field
Posted by Marcus <ma...@wtnet.de>.
Am 03/26/2016 12:13 AM, schrieb Andrea Pescetti:
> On 25/03/2016 Marcus wrote:
>
>> Within this thread the agreemnt seems to be to use RESOLVED - MANAGED or
>> RESOLVED - DONE. In the meantime I tent to RESOLVED - DONE.
>
> If the aim is to create less confusion, all proposals I've seen have the
> result of bringing more confusion! So:
I don't see why this brings more confusion. It's the opposite, one
status for "resolved with a code fix" and the other for "resolved
somehow else".
> - FIXED, MANAGED, DONE are very close in meaning, at least for me. If
> you want to single out the "nothing to do with code" situation, I
> recommend that we go for something more explicit, like NOCODE or
> similar. So RESOLVED-NOCODE would simply mean "resolved without any code
> being committed". It doesn't have to be "NOCODE", but it should be
> something that means "nothing to do with code", and DONE does not really
> convey the right meaning here.
Then NOCODEFIX sounds more concrete.
Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Can we add the value "N/A" to the Target Milestone field
Posted by Andrea Pescetti <pe...@apache.org>.
On 25/03/2016 Marcus wrote:
> We want to use a different resolution status to underline that the
> respective issue *and* its solution has nothing to do with the code. And
> that's the topic of this mail thread.
And this is clear to me, but I totally don't get why one needs to do
that, except for automated searches.
> This is very helpful especially when you create a search and you can see
> at first view in the result list which issue is code related and which
> is not.
OK, let's assume that automated searches are important (and they indeed
are useful starting points for QA). I can understand that one may want
to verify defects and not be distracted by issues about wiki content
fixes, or support requests that got answered.
> Within this thread the agreemnt seems to be to use RESOLVED - MANAGED or
> RESOLVED - DONE. In the meantime I tent to RESOLVED - DONE.
If the aim is to create less confusion, all proposals I've seen have the
result of bringing more confusion! So:
- If we have RESOLVED-FIXED for code and RESOLVED-XYZ for non-code then
we can remove the "NONE" or "N/A" from target, right? Otherwise we
create more useless cases.
- FIXED, MANAGED, DONE are very close in meaning, at least for me. If
you want to single out the "nothing to do with code" situation, I
recommend that we go for something more explicit, like NOCODE or
similar. So RESOLVED-NOCODE would simply mean "resolved without any code
being committed". It doesn't have to be "NOCODE", but it should be
something that means "nothing to do with code", and DONE does not really
convey the right meaning here.
Regards,
Andrea.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Can we add the value "N/A" to the Target Milestone field
Posted by Marcus <ma...@wtnet.de>.
Am 03/25/2016 08:58 PM, schrieb Andrea Pescetti:
> On 22/03/2016 Marcus wrote:
>> @all:
>> It seems we could have a consensus in creating a new MANAGED or DONE
>> status to set when issues are no real code problems, but more
>> user-oriented. Finally, they were solved for the user's satisfaction
>> (e.g., provided how-to's or repaired documents, etc.). However, no fix
>> in the source code has been done.
>
> When something is fixed, it's fixed. Why bother inventing new terminology?
because your first sentence is already wrong. ;-)
> For an issue that impacts code (example: update a library)
> RESOLVED-FIXED means that the source code was updated. Bugzilla tracks
> the relevant commit. A target might be set by the developer who is
> taking care of the fix to make it clearer what version will contain the
> fix. I always use it, but I don't consider it mandatory.
*When* a code fix is involved, then this paragraph is correct ...
> For an issue that does not impact code (example: fix a page on the Wiki)
> I've always used RESOLVED-FIXED too. I don't see a reason to
> differentiate this case from the one above: for the reporter, this is
> fixed.
... but this is not correct (or not pefect if you want) when thinking a
bit more.
Our BZ is used more and more for normal user problems and help desk
topics. These are mosty not code-related. I don't like this. But the
solution would be to install someone as gatekeeper that stops any
user-problem discussion immediatelly and closing these issues. This is
not a good user experience. So, I think we have to live with user
problems in our BZ.
> Still, if we want to differentiate, I agree that we could be stricter in
> always assigning a target when something is marked RESOLVED-FIXED (at
> latest). If it is a code fix the target will be a version, if it is not
> related to any specific version the target will be the new NONE (or N/A,
> or whatever conveys the meaning of "not applicable").
We want to use a different resolution status to underline that the
respective issue *and* its solution has nothing to do with the code. And
that's the topic of this mail thread.
This is very helpful especially when you create a search and you can see
at first view in the result list which issue is code related and which
is not.
BTW:
That's also the reason why other issue trackers like JIRA have different
resolution status for issues that are resolved. To make it visible very
easy and fast to see what's up.
Of course you have to use it correct to reach this goal. But using
$your_favorite_issue_tracker in the right way this a completely
different topic. ;-)
Within this thread the agreemnt seems to be to use RESOLVED - MANAGED or
RESOLVED - DONE. In the meantime I tent to RESOLVED - DONE.
Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Can we add the value "N/A" to the Target Milestone field
Posted by Andrea Pescetti <pe...@apache.org>.
On 22/03/2016 Marcus wrote:
> @all:
> It seems we could have a consensus in creating a new MANAGED or DONE
> status to set when issues are no real code problems, but more
> user-oriented. Finally, they were solved for the user's satisfaction
> (e.g., provided how-to's or repaired documents, etc.). However, no fix
> in the source code has been done.
When something is fixed, it's fixed. Why bother inventing new terminology?
For an issue that impacts code (example: update a library)
RESOLVED-FIXED means that the source code was updated. Bugzilla tracks
the relevant commit. A target might be set by the developer who is
taking care of the fix to make it clearer what version will contain the
fix. I always use it, but I don't consider it mandatory.
For an issue that does not impact code (example: fix a page on the Wiki)
I've always used RESOLVED-FIXED too. I don't see a reason to
differentiate this case from the one above: for the reporter, this is fixed.
Still, if we want to differentiate, I agree that we could be stricter in
always assigning a target when something is marked RESOLVED-FIXED (at
latest). If it is a code fix the target will be a version, if it is not
related to any specific version the target will be the new NONE (or N/A,
or whatever conveys the meaning of "not applicable").
Regards,
Andrea.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Can we add the value "N/A" to the Target Milestone field
Posted by Marcus <ma...@wtnet.de>.
Am 03/22/2016 04:48 PM, schrieb Dennis E. Hamilton:
> Many interesting ideas, ...
>
>> -----Original Message-----
>> From: Carl Marcum [mailto:cmarcum@apache.org]
>> Sent: Tuesday, March 22, 2016 03:35
>> To: dev@openoffice.apache.org
>> Subject: Re: Can we add the value "N/A" to the Target Milestone field
>>
>> On 03/22/2016 05:02 AM, Marcus wrote:
>>> Am 03/22/2016 10:00 AM, schrieb Marcus:
> [ ,,, ]
>>>> [ ... ] what about RESOLVED -
>> MANAGED?
>>>> This word is maybe better known in the world. This term shows that
>> the
>>>> issue has some work in it and was tackled. With a closing comment you
>>>> can see where and why it was successful managed (resolved).
>>>
>>> from Jira I also know that RESOLVED - DONE is a common way to say that
>>> an issue was successfully resolved.
>>>
>>> Marcus
>>>
>> Having a RESOLVED - DONE would be especially good for tasks also.
>>
> [orcmid]
>
> MANAGED is interesting because of its flexibility. How it was managed should be accounted for in the commentary.
ACK
> DONE does seem to apply to Tasks and Enhancement requests.
Right, and user requests are very often nothing else (e.g., "my document
is broken, how to repair it?").
> DECLINED also seems to apply to both Tasks and Enhancements. It is also a counterpart to ACCEPTED in those cases.
Yes, it doesn't indicate that there is a solution/workaround available.
@all:
It seems we could have a consensus in creating a new MANAGED or DONE
status to set when issues are no real code problems, but more
user-oriented. Finally, they were solved for the user's satisfaction
(e.g., provided how-to's or repaired documents, etc.). However, no fix
in the source code has been done.
> At qa@ Pedro Lino made some useful observations about how terms impact reporters and observers of the Bugzilla activity.
>
> In respect to that, I have been using WONTFIX as a way to indicate that we have no capacity to do anything about an issue, especially a longstanding one. This is primarily a way of discouraging non-project commenters arguing among themselves and to also indicate that the issue is understood, recognized, and continued lobbying is not useful. I think DECLINED may be useful in some of those cases, but WONTFIX is more truthful when the project doesn't have a way to do anything. NOTFIXING is closer to the reality. (CANTFIX would also indicate that the problem is not with the issue, but with project capability at this time.) The door is not closed completely, but it is not clear when the door will ever be opened.
>
> I agree that we do need a diagram and a description of the general application of Bugzilla categories and resolution cases. We might also need to revisit how the search defaults work with respect to the various categories. This seems like a good Wiki [update] effort. We also don't want to split things into so many categories that application and understanding becomes more difficult.
After we have an agreement I can take over this task to grep the data in
Wiki to consolidate and update them with the new information.
Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Can we add the value "N/A" to the Target Milestone field
Posted by Marcus <ma...@wtnet.de>.
Am 03/22/2016 04:48 PM, schrieb Dennis E. Hamilton:
> Many interesting ideas, ...
>
>> -----Original Message-----
>> From: Carl Marcum [mailto:cmarcum@apache.org]
>> Sent: Tuesday, March 22, 2016 03:35
>> To: dev@openoffice.apache.org
>> Subject: Re: Can we add the value "N/A" to the Target Milestone field
>>
>> On 03/22/2016 05:02 AM, Marcus wrote:
>>> Am 03/22/2016 10:00 AM, schrieb Marcus:
> [ ,,, ]
>>>> [ ... ] what about RESOLVED -
>> MANAGED?
>>>> This word is maybe better known in the world. This term shows that
>> the
>>>> issue has some work in it and was tackled. With a closing comment you
>>>> can see where and why it was successful managed (resolved).
>>>
>>> from Jira I also know that RESOLVED - DONE is a common way to say that
>>> an issue was successfully resolved.
>>>
>>> Marcus
>>>
>> Having a RESOLVED - DONE would be especially good for tasks also.
>>
> [orcmid]
>
> MANAGED is interesting because of its flexibility. How it was managed should be accounted for in the commentary.
ACK
> DONE does seem to apply to Tasks and Enhancement requests.
Right, and user requests are very often nothing else (e.g., "my document
is broken, how to repair it?").
> DECLINED also seems to apply to both Tasks and Enhancements. It is also a counterpart to ACCEPTED in those cases.
Yes, it doesn't indicate that there is a solution/workaround available.
@all:
It seems we could have a consensus in creating a new MANAGED or DONE
status to set when issues are no real code problems, but more
user-oriented. Finally, they were solved for the user's satisfaction
(e.g., provided how-to's or repaired documents, etc.). However, no fix
in the source code has been done.
> At qa@ Pedro Lino made some useful observations about how terms impact reporters and observers of the Bugzilla activity.
>
> In respect to that, I have been using WONTFIX as a way to indicate that we have no capacity to do anything about an issue, especially a longstanding one. This is primarily a way of discouraging non-project commenters arguing among themselves and to also indicate that the issue is understood, recognized, and continued lobbying is not useful. I think DECLINED may be useful in some of those cases, but WONTFIX is more truthful when the project doesn't have a way to do anything. NOTFIXING is closer to the reality. (CANTFIX would also indicate that the problem is not with the issue, but with project capability at this time.) The door is not closed completely, but it is not clear when the door will ever be opened.
>
> I agree that we do need a diagram and a description of the general application of Bugzilla categories and resolution cases. We might also need to revisit how the search defaults work with respect to the various categories. This seems like a good Wiki [update] effort. We also don't want to split things into so many categories that application and understanding becomes more difficult.
After we have an agreement I can take over this task to grep the data in
Wiki to consolidate and update them with the new information.
Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
For additional commands, e-mail: qa-help@openoffice.apache.org
RE: Can we add the value "N/A" to the Target Milestone field
Posted by "Dennis E. Hamilton" <de...@acm.org>.
Many interesting ideas, ...
> -----Original Message-----
> From: Carl Marcum [mailto:cmarcum@apache.org]
> Sent: Tuesday, March 22, 2016 03:35
> To: dev@openoffice.apache.org
> Subject: Re: Can we add the value "N/A" to the Target Milestone field
>
> On 03/22/2016 05:02 AM, Marcus wrote:
> > Am 03/22/2016 10:00 AM, schrieb Marcus:
[ ,,, ]
> >> [ ... ] what about RESOLVED -
> MANAGED?
> >> This word is maybe better known in the world. This term shows that
> the
> >> issue has some work in it and was tackled. With a closing comment you
> >> can see where and why it was successful managed (resolved).
> >
> > from Jira I also know that RESOLVED - DONE is a common way to say that
> > an issue was successfully resolved.
> >
> > Marcus
> >
> Having a RESOLVED - DONE would be especially good for tasks also.
>
[orcmid]
MANAGED is interesting because of its flexibility. How it was managed should be accounted for in the commentary.
DONE does seem to apply to Tasks and Enhancement requests.
DECLINED also seems to apply to both Tasks and Enhancements. It is also a counterpart to ACCEPTED in those cases.
At qa@ Pedro Lino made some useful observations about how terms impact reporters and observers of the Bugzilla activity.
In respect to that, I have been using WONTFIX as a way to indicate that we have no capacity to do anything about an issue, especially a longstanding one. This is primarily a way of discouraging non-project commenters arguing among themselves and to also indicate that the issue is understood, recognized, and continued lobbying is not useful. I think DECLINED may be useful in some of those cases, but WONTFIX is more truthful when the project doesn't have a way to do anything. NOTFIXING is closer to the reality. (CANTFIX would also indicate that the problem is not with the issue, but with project capability at this time.) The door is not closed completely, but it is not clear when the door will ever be opened.
I agree that we do need a diagram and a description of the general application of Bugzilla categories and resolution cases. We might also need to revisit how the search defaults work with respect to the various categories. This seems like a good Wiki [update] effort. We also don't want to split things into so many categories that application and understanding becomes more difficult.
Looking forward to the further discussion,
- Dennis
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
RE: Can we add the value "N/A" to the Target Milestone field
Posted by "Dennis E. Hamilton" <de...@acm.org>.
Many interesting ideas, ...
> -----Original Message-----
> From: Carl Marcum [mailto:cmarcum@apache.org]
> Sent: Tuesday, March 22, 2016 03:35
> To: dev@openoffice.apache.org
> Subject: Re: Can we add the value "N/A" to the Target Milestone field
>
> On 03/22/2016 05:02 AM, Marcus wrote:
> > Am 03/22/2016 10:00 AM, schrieb Marcus:
[ ,,, ]
> >> [ ... ] what about RESOLVED -
> MANAGED?
> >> This word is maybe better known in the world. This term shows that
> the
> >> issue has some work in it and was tackled. With a closing comment you
> >> can see where and why it was successful managed (resolved).
> >
> > from Jira I also know that RESOLVED - DONE is a common way to say that
> > an issue was successfully resolved.
> >
> > Marcus
> >
> Having a RESOLVED - DONE would be especially good for tasks also.
>
[orcmid]
MANAGED is interesting because of its flexibility. How it was managed should be accounted for in the commentary.
DONE does seem to apply to Tasks and Enhancement requests.
DECLINED also seems to apply to both Tasks and Enhancements. It is also a counterpart to ACCEPTED in those cases.
At qa@ Pedro Lino made some useful observations about how terms impact reporters and observers of the Bugzilla activity.
In respect to that, I have been using WONTFIX as a way to indicate that we have no capacity to do anything about an issue, especially a longstanding one. This is primarily a way of discouraging non-project commenters arguing among themselves and to also indicate that the issue is understood, recognized, and continued lobbying is not useful. I think DECLINED may be useful in some of those cases, but WONTFIX is more truthful when the project doesn't have a way to do anything. NOTFIXING is closer to the reality. (CANTFIX would also indicate that the problem is not with the issue, but with project capability at this time.) The door is not closed completely, but it is not clear when the door will ever be opened.
I agree that we do need a diagram and a description of the general application of Bugzilla categories and resolution cases. We might also need to revisit how the search defaults work with respect to the various categories. This seems like a good Wiki [update] effort. We also don't want to split things into so many categories that application and understanding becomes more difficult.
Looking forward to the further discussion,
- Dennis
---------------------------------------------------------------------
To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
For additional commands, e-mail: qa-help@openoffice.apache.org
Re: Can we add the value "N/A" to the Target Milestone field
Posted by Carl Marcum <cm...@apache.org>.
On 03/22/2016 05:02 AM, Marcus wrote:
> Am 03/22/2016 10:00 AM, schrieb Marcus:
>> Am 03/22/2016 03:37 AM, schrieb Dennis E. Hamilton:
>>>
>>>> -----Original Message-----
>>>> From: Pedro Lino [mailto:pedlino@gmail.com]
>>>> Sent: Monday, March 21, 2016 16:53
>>>> To: qa@openoffice.apache.org
>>>> Subject: Re: Can we add the value "N/A" to the Target Milestone field
>>>>
>>>>> It's not about to draw the line between issues that are resolved and
>>>>> verified solutions. It's about to differentiate issues that are in
>>>>> the
>>>> real
>>>>> application and therefore need to be fixed in the source code.
>>>>> Here we
>>>> use
>>>>> (or better should use) RESOLVED - FIXED.
>>>>>
>>>>> But what about issues that are also reporting a problem but the
>>>> solution
>>>>> (if there is any) is somewhere else? RESOLVED - FIXED doesn't fit,
>>>> RESOLVED
>>>>> - NOT_AN_ISSUE also not.
>>>>>
>>>>
>>>> Why not use the same nomenclature as the "sibling project"? RESOLVED -
>>>> NOTOURBUG
>>> [orcmid]
>>>
>>> It seems to me that RESOLVED - RESOLVED is too mysterious and RESOLVED
>>> - NOTOURBUG is not much better than NOTANISSUE.
>>>
>>> RESOLVED - HANDLED might be closer, with the comment that achieves
>>> this explains how it is handled. (I.e., documentation, workaround,
>>> whatever.)
>>>
>>> I'm not in love with that term and don't know how it works for
>>> non-native English-language participants.
>>
>> I like it as it is more general. However, what about RESOLVED - MANAGED?
>> This word is maybe better known in the world. This term shows that the
>> issue has some work in it and was tackled. With a closing comment you
>> can see where and why it was successful managed (resolved).
>
> from Jira I also know that RESOLVED - DONE is a common way to say that
> an issue was successfully resolved.
>
> Marcus
>
Having a RESOLVED - DONE would be especially good for tasks also.
Carl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Can we add the value "N/A" to the Target Milestone field
Posted by Marcus <ma...@wtnet.de>.
Am 03/23/2016 12:29 AM, schrieb Dennis E. Hamilton:
>
>
>> -----Original Message-----
>> From: Marcus [mailto:marcus.mail@wtnet.de]
>> Sent: Tuesday, March 22, 2016 11:30
>> To: dev@openoffice.apache.org
>> Subject: Re: Can we add the value "N/A" to the Target Milestone field
>>
>> Am 03/22/2016 06:34 PM, schrieb Patricia Shanahan:
>>> On 3/22/2016 9:25 AM, Marcus wrote:
>>> ...
>>>> OK, it seems you also like the idea to have another resolution status
>> -
>>>> it just depends on what the name is, right? ;-)
>>> ...
>>>
>>> How about RESOLVED - WENEEDPEOPLE for issues where we would like to do
>> a
>>> fix or enhancement, and are only being prevented by lack of volunteers
>>> to do the work? Maybe that would motivate people who want fixes to do
>>> some recruiting.
>>
>> IMHO this doesn't fit together. Either the issue is resolved or not.
>> RESOLVED - WENEEDPEOPLE means both which doesn't make sense here - at
>> least for me. ;-)
>>
>> For issues where some more people involvement is need, just leave the
>> issue open with status CONFIRMED or ACCEPTED and a respective comment.
>>
> [orcmid]
>
> When the issue has been lingering without movement, I think WONTFIX is an important signal. If that is taken to be too harsh, NO_RESOURCES (or NEED_RESOURCES) might be another way when it is a resource issue and not a disagreement about the importance of a fix. It gives people something to search on in looking for possible activities.
sure. after a longer time without any change on that kind of issue, it
should be closed. Additionally you can set the keyword "needhelp" to
give this issue a bit more expression and it's easier to do a search in
BZ find all these issues.
Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
RE: Can we add the value "N/A" to the Target Milestone field
Posted by "Dennis E. Hamilton" <de...@acm.org>.
> -----Original Message-----
> From: Marcus [mailto:marcus.mail@wtnet.de]
> Sent: Tuesday, March 22, 2016 11:30
> To: dev@openoffice.apache.org
> Subject: Re: Can we add the value "N/A" to the Target Milestone field
>
> Am 03/22/2016 06:34 PM, schrieb Patricia Shanahan:
> > On 3/22/2016 9:25 AM, Marcus wrote:
> > ...
> >> OK, it seems you also like the idea to have another resolution status
> -
> >> it just depends on what the name is, right? ;-)
> > ...
> >
> > How about RESOLVED - WENEEDPEOPLE for issues where we would like to do
> a
> > fix or enhancement, and are only being prevented by lack of volunteers
> > to do the work? Maybe that would motivate people who want fixes to do
> > some recruiting.
>
> IMHO this doesn't fit together. Either the issue is resolved or not.
> RESOLVED - WENEEDPEOPLE means both which doesn't make sense here - at
> least for me. ;-)
>
> For issues where some more people involvement is need, just leave the
> issue open with status CONFIRMED or ACCEPTED and a respective comment.
>
[orcmid]
When the issue has been lingering without movement, I think WONTFIX is an important signal. If that is taken to be too harsh, NO_RESOURCES (or NEED_RESOURCES) might be another way when it is a resource issue and not a disagreement about the importance of a fix. It gives people something to search on in looking for possible activities.
> My 2 ct.
>
> Marcus
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Can we add the value "N/A" to the Target Milestone field
Posted by Marcus <ma...@wtnet.de>.
Am 03/22/2016 06:34 PM, schrieb Patricia Shanahan:
> On 3/22/2016 9:25 AM, Marcus wrote:
> ...
>> OK, it seems you also like the idea to have another resolution status -
>> it just depends on what the name is, right? ;-)
> ...
>
> How about RESOLVED - WENEEDPEOPLE for issues where we would like to do a
> fix or enhancement, and are only being prevented by lack of volunteers
> to do the work? Maybe that would motivate people who want fixes to do
> some recruiting.
IMHO this doesn't fit together. Either the issue is resolved or not.
RESOLVED - WENEEDPEOPLE means both which doesn't make sense here - at
least for me. ;-)
For issues where some more people involvement is need, just leave the
issue open with status CONFIRMED or ACCEPTED and a respective comment.
My 2 ct.
Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Can we add the value "N/A" to the Target Milestone field
Posted by Patricia Shanahan <pa...@acm.org>.
On 3/22/2016 9:25 AM, Marcus wrote:
...
> OK, it seems you also like the idea to have another resolution status -
> it just depends on what the name is, right? ;-)
...
How about RESOLVED - WENEEDPEOPLE for issues where we would like to do a
fix or enhancement, and are only being prevented by lack of volunteers
to do the work? Maybe that would motivate people who want fixes to do
some recruiting.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
RE: Can we add the value "N/A" to the Target Milestone field
Posted by "Dennis E. Hamilton" <de...@acm.org>.
So long as you still have use of the old email address, you can do this.
Using the old email address, send a message to
<qa...@openoffice.apache.org> with UNSUBSCRIBE in the
subject and body. A message will be sent to that email asking
for confirmation. Reply to that message in the manner specified
and it should work.
Note that dgoldfield@asb.org is not subscribed to this (qa@) list and you will need to subscribe it if you intend to follow the list in the future.
If you don't have use of the old address, you need to tell us what it is so that we can show you how to unsubscribe it.
- Dennis
> -----Original Message-----
> From: David Goldfield [mailto:dgoldfield@asb.org]
> Sent: Tuesday, March 22, 2016 05:42
> To: qa@openoffice.apache.org
> Subject: RE: Can we add the value "N/A" to the Target Milestone field
>
> Hi. I'll be switching email addresses and I'd like to know if there's an
> email address I can use for a quick unsubscribe from this list.
>
>
>
> David Goldfield
> 919 Walnut Street
>
> Philadelphia, Pennsylvania, 19107
>
> 215-627-0600
> FAX: 215-922-0692
> mailto:dgoldfield@asb.org
> http://www.asb.org
> Amazon Smiles ASB
> http://www.asb.org/images/Amazon_Smiles.jpg
> Serving Philadelphia's and the nation's blind and visually impaired
> population since 1874.
> -----Original Message-----
> From: Pedro Lino [mailto:pedlino@gmail.com]
> Sent: Tuesday, March 22, 2016 6:57 AM
> To: qa@openoffice.apache.org
> Subject: Re: Can we add the value "N/A" to the Target Milestone field
>
> > It seems to me that RESOLVED - RESOLVED is too mysterious and RESOLVED
> >>> - NOTOURBUG is not much better than NOTANISSUE.
> >>>
> >>> RESOLVED - HANDLED might be closer, with the comment that achieves
> >>> this explains how it is handled. (I.e., documentation, workaround,
> >>> whatever.)
> >>>
> >>> I'm not in love with that term and don't know how it works for
> >>> non-native English-language participants.
> >>>
> >>
> >> I like it as it is more general. However, what about RESOLVED -
> MANAGED?
> >> This word is maybe better known in the world. This term shows that
> >> the issue has some work in it and was tackled. With a closing comment
> >> you can see where and why it was successful managed (resolved).
> >>
> >
> > from Jira I also know that RESOLVED - DONE is a common way to say that
> > an issue was successfully resolved.
> >
>
> NOT_AN_ISSUE seems a bad option. The problem which is affecting someone
> is dismissed. In my opinion it is as as offensive as WORKSFORME (used in
> LibreOffice) and WONT_FIX (used in both projects)
>
> HANDLED, MANAGED only applies if there are workarounds (which is not
> always the case).
>
> NOTOURBUG means that the Devs looked at it and although they recognize
> it's a problem, there is nothing they can do because the problem is
> somewhere else.
> I agree it's a but short and rough but it's difficult to be nice and
> meaningful with a single word (or glued words). This can be further
> explained in the Comments when changing status if the developer is in
> such a mood...
>
> NOTABUG could be used instead of WONT_FIX (when it's reported as a bug
> but AOO decides it is working as expected) and DECLINED when it's a
> suggestion/enhancement (and AOO decides it is not
> interesting/productive)
>
> Just my 2 cents ;)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: qa-help@openoffice.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
For additional commands, e-mail: qa-help@openoffice.apache.org
RE: Can we add the value "N/A" to the Target Milestone field
Posted by David Goldfield <dg...@asb.org>.
Hi. I'll be switching email addresses and I'd like to know if there's an email address I can use for a quick unsubscribe from this list.
David Goldfield
919 Walnut Street
Philadelphia, Pennsylvania, 19107
215-627-0600
FAX: 215-922-0692
mailto:dgoldfield@asb.org
http://www.asb.org
Amazon Smiles ASB
http://www.asb.org/images/Amazon_Smiles.jpg
Serving Philadelphia's and the nation's blind and visually impaired population since 1874.
-----Original Message-----
From: Pedro Lino [mailto:pedlino@gmail.com]
Sent: Tuesday, March 22, 2016 6:57 AM
To: qa@openoffice.apache.org
Subject: Re: Can we add the value "N/A" to the Target Milestone field
> It seems to me that RESOLVED - RESOLVED is too mysterious and RESOLVED
>>> - NOTOURBUG is not much better than NOTANISSUE.
>>>
>>> RESOLVED - HANDLED might be closer, with the comment that achieves
>>> this explains how it is handled. (I.e., documentation, workaround,
>>> whatever.)
>>>
>>> I'm not in love with that term and don't know how it works for
>>> non-native English-language participants.
>>>
>>
>> I like it as it is more general. However, what about RESOLVED - MANAGED?
>> This word is maybe better known in the world. This term shows that
>> the issue has some work in it and was tackled. With a closing comment
>> you can see where and why it was successful managed (resolved).
>>
>
> from Jira I also know that RESOLVED - DONE is a common way to say that
> an issue was successfully resolved.
>
NOT_AN_ISSUE seems a bad option. The problem which is affecting someone is dismissed. In my opinion it is as as offensive as WORKSFORME (used in
LibreOffice) and WONT_FIX (used in both projects)
HANDLED, MANAGED only applies if there are workarounds (which is not always the case).
NOTOURBUG means that the Devs looked at it and although they recognize it's a problem, there is nothing they can do because the problem is somewhere else.
I agree it's a but short and rough but it's difficult to be nice and meaningful with a single word (or glued words). This can be further explained in the Comments when changing status if the developer is in such a mood...
NOTABUG could be used instead of WONT_FIX (when it's reported as a bug but AOO decides it is working as expected) and DECLINED when it's a suggestion/enhancement (and AOO decides it is not interesting/productive)
Just my 2 cents ;)
---------------------------------------------------------------------
To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
For additional commands, e-mail: qa-help@openoffice.apache.org
Re: Can we add the value "N/A" to the Target Milestone field
Posted by Marcus <ma...@wtnet.de>.
Am 03/22/2016 11:56 AM, schrieb Pedro Lino:
>> It seems to me that RESOLVED - RESOLVED is too mysterious and RESOLVED
>>>> - NOTOURBUG is not much better than NOTANISSUE.
>>>>
>>>> RESOLVED - HANDLED might be closer, with the comment that achieves
>>>> this explains how it is handled. (I.e., documentation, workaround,
>>>> whatever.)
>>>>
>>>> I'm not in love with that term and don't know how it works for
>>>> non-native English-language participants.
>>>>
>>>
>>> I like it as it is more general. However, what about RESOLVED - MANAGED?
>>> This word is maybe better known in the world. This term shows that the
>>> issue has some work in it and was tackled. With a closing comment you
>>> can see where and why it was successful managed (resolved).
>>>
>>
>> from Jira I also know that RESOLVED - DONE is a common way to say that an
>> issue was successfully resolved.
>>
>
> NOT_AN_ISSUE seems a bad option. The problem which is affecting someone is
> dismissed. In my opinion it is as as offensive as WORKSFORME (used in
> LibreOffice) and WONT_FIX (used in both projects)
+1 and additionally it doesn't show that the issue was solved.
> HANDLED, MANAGED only applies if there are workarounds (which is not always
> the case).
No, I see this different. For me the wording is more general. So, it's
not that important if there is a real solution or workaround or whatever
for the iassue.
> NOTOURBUG means that the Devs looked at it and although they recognize it's
> a problem, there is nothing they can do because the problem is somewhere
> else.
> I agree it's a but short and rough but it's difficult to be nice and
> meaningful with a single word (or glued words). This can be further
> explained in the Comments when changing status if the developer is in such
> a mood...
>
> NOTABUG could be used instead of WONT_FIX (when it's reported as a bug but
> AOO decides it is working as expected) and DECLINED when it's a
> suggestion/enhancement (and AOO decides it is not interesting/productive)
Additionally with NOTOURBUG and NOTABUG you cannot see that the issue
has a workable and accepted solution. But this is a key point of this
whole discussion.
OK, it seems you also like the idea to have another resolution status -
it just depends on what the name is, right? ;-)
Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Can we add the value "N/A" to the Target Milestone field
Posted by Marcus <ma...@wtnet.de>.
Am 03/22/2016 11:56 AM, schrieb Pedro Lino:
>> It seems to me that RESOLVED - RESOLVED is too mysterious and RESOLVED
>>>> - NOTOURBUG is not much better than NOTANISSUE.
>>>>
>>>> RESOLVED - HANDLED might be closer, with the comment that achieves
>>>> this explains how it is handled. (I.e., documentation, workaround,
>>>> whatever.)
>>>>
>>>> I'm not in love with that term and don't know how it works for
>>>> non-native English-language participants.
>>>>
>>>
>>> I like it as it is more general. However, what about RESOLVED - MANAGED?
>>> This word is maybe better known in the world. This term shows that the
>>> issue has some work in it and was tackled. With a closing comment you
>>> can see where and why it was successful managed (resolved).
>>>
>>
>> from Jira I also know that RESOLVED - DONE is a common way to say that an
>> issue was successfully resolved.
>>
>
> NOT_AN_ISSUE seems a bad option. The problem which is affecting someone is
> dismissed. In my opinion it is as as offensive as WORKSFORME (used in
> LibreOffice) and WONT_FIX (used in both projects)
+1 and additionally it doesn't show that the issue was solved.
> HANDLED, MANAGED only applies if there are workarounds (which is not always
> the case).
No, I see this different. For me the wording is more general. So, it's
not that important if there is a real solution or workaround or whatever
for the iassue.
> NOTOURBUG means that the Devs looked at it and although they recognize it's
> a problem, there is nothing they can do because the problem is somewhere
> else.
> I agree it's a but short and rough but it's difficult to be nice and
> meaningful with a single word (or glued words). This can be further
> explained in the Comments when changing status if the developer is in such
> a mood...
>
> NOTABUG could be used instead of WONT_FIX (when it's reported as a bug but
> AOO decides it is working as expected) and DECLINED when it's a
> suggestion/enhancement (and AOO decides it is not interesting/productive)
Additionally with NOTOURBUG and NOTABUG you cannot see that the issue
has a workable and accepted solution. But this is a key point of this
whole discussion.
OK, it seems you also like the idea to have another resolution status -
it just depends on what the name is, right? ;-)
Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
For additional commands, e-mail: qa-help@openoffice.apache.org
Re: Can we add the value "N/A" to the Target Milestone field
Posted by Pedro Lino <pe...@gmail.com>.
> It seems to me that RESOLVED - RESOLVED is too mysterious and RESOLVED
>>> - NOTOURBUG is not much better than NOTANISSUE.
>>>
>>> RESOLVED - HANDLED might be closer, with the comment that achieves
>>> this explains how it is handled. (I.e., documentation, workaround,
>>> whatever.)
>>>
>>> I'm not in love with that term and don't know how it works for
>>> non-native English-language participants.
>>>
>>
>> I like it as it is more general. However, what about RESOLVED - MANAGED?
>> This word is maybe better known in the world. This term shows that the
>> issue has some work in it and was tackled. With a closing comment you
>> can see where and why it was successful managed (resolved).
>>
>
> from Jira I also know that RESOLVED - DONE is a common way to say that an
> issue was successfully resolved.
>
NOT_AN_ISSUE seems a bad option. The problem which is affecting someone is
dismissed. In my opinion it is as as offensive as WORKSFORME (used in
LibreOffice) and WONT_FIX (used in both projects)
HANDLED, MANAGED only applies if there are workarounds (which is not always
the case).
NOTOURBUG means that the Devs looked at it and although they recognize it's
a problem, there is nothing they can do because the problem is somewhere
else.
I agree it's a but short and rough but it's difficult to be nice and
meaningful with a single word (or glued words). This can be further
explained in the Comments when changing status if the developer is in such
a mood...
NOTABUG could be used instead of WONT_FIX (when it's reported as a bug but
AOO decides it is working as expected) and DECLINED when it's a
suggestion/enhancement (and AOO decides it is not interesting/productive)
Just my 2 cents ;)
Re: Can we add the value "N/A" to the Target Milestone field
Posted by Marcus <ma...@wtnet.de>.
Am 03/22/2016 10:00 AM, schrieb Marcus:
> Am 03/22/2016 03:37 AM, schrieb Dennis E. Hamilton:
>>
>>> -----Original Message-----
>>> From: Pedro Lino [mailto:pedlino@gmail.com]
>>> Sent: Monday, March 21, 2016 16:53
>>> To: qa@openoffice.apache.org
>>> Subject: Re: Can we add the value "N/A" to the Target Milestone field
>>>
>>>> It's not about to draw the line between issues that are resolved and
>>>> verified solutions. It's about to differentiate issues that are in the
>>> real
>>>> application and therefore need to be fixed in the source code. Here we
>>> use
>>>> (or better should use) RESOLVED - FIXED.
>>>>
>>>> But what about issues that are also reporting a problem but the
>>> solution
>>>> (if there is any) is somewhere else? RESOLVED - FIXED doesn't fit,
>>> RESOLVED
>>>> - NOT_AN_ISSUE also not.
>>>>
>>>
>>> Why not use the same nomenclature as the "sibling project"? RESOLVED -
>>> NOTOURBUG
>> [orcmid]
>>
>> It seems to me that RESOLVED - RESOLVED is too mysterious and RESOLVED
>> - NOTOURBUG is not much better than NOTANISSUE.
>>
>> RESOLVED - HANDLED might be closer, with the comment that achieves
>> this explains how it is handled. (I.e., documentation, workaround,
>> whatever.)
>>
>> I'm not in love with that term and don't know how it works for
>> non-native English-language participants.
>
> I like it as it is more general. However, what about RESOLVED - MANAGED?
> This word is maybe better known in the world. This term shows that the
> issue has some work in it and was tackled. With a closing comment you
> can see where and why it was successful managed (resolved).
from Jira I also know that RESOLVED - DONE is a common way to say that
an issue was successfully resolved.
Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
For additional commands, e-mail: qa-help@openoffice.apache.org
Re: Can we add the value "N/A" to the Target Milestone field
Posted by Marcus <ma...@wtnet.de>.
Am 03/22/2016 10:00 AM, schrieb Marcus:
> Am 03/22/2016 03:37 AM, schrieb Dennis E. Hamilton:
>>
>>> -----Original Message-----
>>> From: Pedro Lino [mailto:pedlino@gmail.com]
>>> Sent: Monday, March 21, 2016 16:53
>>> To: qa@openoffice.apache.org
>>> Subject: Re: Can we add the value "N/A" to the Target Milestone field
>>>
>>>> It's not about to draw the line between issues that are resolved and
>>>> verified solutions. It's about to differentiate issues that are in the
>>> real
>>>> application and therefore need to be fixed in the source code. Here we
>>> use
>>>> (or better should use) RESOLVED - FIXED.
>>>>
>>>> But what about issues that are also reporting a problem but the
>>> solution
>>>> (if there is any) is somewhere else? RESOLVED - FIXED doesn't fit,
>>> RESOLVED
>>>> - NOT_AN_ISSUE also not.
>>>>
>>>
>>> Why not use the same nomenclature as the "sibling project"? RESOLVED -
>>> NOTOURBUG
>> [orcmid]
>>
>> It seems to me that RESOLVED - RESOLVED is too mysterious and RESOLVED
>> - NOTOURBUG is not much better than NOTANISSUE.
>>
>> RESOLVED - HANDLED might be closer, with the comment that achieves
>> this explains how it is handled. (I.e., documentation, workaround,
>> whatever.)
>>
>> I'm not in love with that term and don't know how it works for
>> non-native English-language participants.
>
> I like it as it is more general. However, what about RESOLVED - MANAGED?
> This word is maybe better known in the world. This term shows that the
> issue has some work in it and was tackled. With a closing comment you
> can see where and why it was successful managed (resolved).
from Jira I also know that RESOLVED - DONE is a common way to say that
an issue was successfully resolved.
Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Can we add the value "N/A" to the Target Milestone field
Posted by Marcus <ma...@wtnet.de>.
Am 03/22/2016 03:37 AM, schrieb Dennis E. Hamilton:
>
>> -----Original Message-----
>> From: Pedro Lino [mailto:pedlino@gmail.com]
>> Sent: Monday, March 21, 2016 16:53
>> To: qa@openoffice.apache.org
>> Subject: Re: Can we add the value "N/A" to the Target Milestone field
>>
>>> It's not about to draw the line between issues that are resolved and
>>> verified solutions. It's about to differentiate issues that are in the
>> real
>>> application and therefore need to be fixed in the source code. Here we
>> use
>>> (or better should use) RESOLVED - FIXED.
>>>
>>> But what about issues that are also reporting a problem but the
>> solution
>>> (if there is any) is somewhere else? RESOLVED - FIXED doesn't fit,
>> RESOLVED
>>> - NOT_AN_ISSUE also not.
>>>
>>
>> Why not use the same nomenclature as the "sibling project"? RESOLVED -
>> NOTOURBUG
> [orcmid]
>
> It seems to me that RESOLVED - RESOLVED is too mysterious and RESOLVED - NOTOURBUG is not much better than NOTANISSUE.
>
> RESOLVED - HANDLED might be closer, with the comment that achieves this explains how it is handled. (I.e., documentation, workaround, whatever.)
>
> I'm not in love with that term and don't know how it works for non-native English-language participants.
I like it as it is more general. However, what about RESOLVED - MANAGED?
This word is maybe better known in the world. This term shows that the
issue has some work in it and was tackled. With a closing comment you
can see where and why it was successful managed (resolved).
>> I believe Apache QA needs a flowchart such as
>>
> https://wiki.documentfoundation.org/images/c/c4/Unconfirmed_Bugs_Status_ Flowchart_Version_0.1.pdf
>> https://wiki.documentfoundation.org/images/c/cb/Unconfirmed_Bugs_Status_Flowchart.odg
> [orcmid]
Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
For additional commands, e-mail: qa-help@openoffice.apache.org
Re: Can we add the value "N/A" to the Target Milestone field
Posted by Marcus <ma...@wtnet.de>.
Am 03/22/2016 03:37 AM, schrieb Dennis E. Hamilton:
>
>> -----Original Message-----
>> From: Pedro Lino [mailto:pedlino@gmail.com]
>> Sent: Monday, March 21, 2016 16:53
>> To: qa@openoffice.apache.org
>> Subject: Re: Can we add the value "N/A" to the Target Milestone field
>>
>>> It's not about to draw the line between issues that are resolved and
>>> verified solutions. It's about to differentiate issues that are in the
>> real
>>> application and therefore need to be fixed in the source code. Here we
>> use
>>> (or better should use) RESOLVED - FIXED.
>>>
>>> But what about issues that are also reporting a problem but the
>> solution
>>> (if there is any) is somewhere else? RESOLVED - FIXED doesn't fit,
>> RESOLVED
>>> - NOT_AN_ISSUE also not.
>>>
>>
>> Why not use the same nomenclature as the "sibling project"? RESOLVED -
>> NOTOURBUG
> [orcmid]
>
> It seems to me that RESOLVED - RESOLVED is too mysterious and RESOLVED - NOTOURBUG is not much better than NOTANISSUE.
>
> RESOLVED - HANDLED might be closer, with the comment that achieves this explains how it is handled. (I.e., documentation, workaround, whatever.)
>
> I'm not in love with that term and don't know how it works for non-native English-language participants.
I like it as it is more general. However, what about RESOLVED - MANAGED?
This word is maybe better known in the world. This term shows that the
issue has some work in it and was tackled. With a closing comment you
can see where and why it was successful managed (resolved).
>> I believe Apache QA needs a flowchart such as
>>
> https://wiki.documentfoundation.org/images/c/c4/Unconfirmed_Bugs_Status_ Flowchart_Version_0.1.pdf
>> https://wiki.documentfoundation.org/images/c/cb/Unconfirmed_Bugs_Status_Flowchart.odg
> [orcmid]
Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
RE: Can we add the value "N/A" to the Target Milestone field
Posted by "Dennis E. Hamilton" <de...@acm.org>.
> -----Original Message-----
> From: Pedro Lino [mailto:pedlino@gmail.com]
> Sent: Monday, March 21, 2016 16:53
> To: qa@openoffice.apache.org
> Subject: Re: Can we add the value "N/A" to the Target Milestone field
>
> > It's not about to draw the line between issues that are resolved and
> > verified solutions. It's about to differentiate issues that are in the
> real
> > application and therefore need to be fixed in the source code. Here we
> use
> > (or better should use) RESOLVED - FIXED.
> >
> > But what about issues that are also reporting a problem but the
> solution
> > (if there is any) is somewhere else? RESOLVED - FIXED doesn't fit,
> RESOLVED
> > - NOT_AN_ISSUE also not.
> >
>
> Why not use the same nomenclature as the "sibling project"? RESOLVED -
> NOTOURBUG
[orcmid]
It seems to me that RESOLVED - RESOLVED is too mysterious and RESOLVED - NOTOURBUG is not much better than NOTANISSUE.
RESOLVED - HANDLED might be closer, with the comment that achieves this explains how it is handled. (I.e., documentation, workaround, whatever.)
I'm not in love with that term and don't know how it works for non-native English-language participants.
>
> I believe Apache QA needs a flowchart such as
>
https://wiki.documentfoundation.org/images/c/c4/Unconfirmed_Bugs_Status_ Flowchart_Version_0.1.pdf
> https://wiki.documentfoundation.org/images/c/cb/Unconfirmed_Bugs_Status_Flowchart.odg
[orcmid]
That's a useful companion topic. (The PDF is apparently defective - Acrobat Reader doesn't see anything in it on Windows.)
The .odg works though. I don't like that flowchart much. I don't think it covers the range that is needed for us. Perhaps it is incomplete and just deals with the front-end of issue triage?
---------------------------------------------------------------------
To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
For additional commands, e-mail: qa-help@openoffice.apache.org
Re: Can we add the value "N/A" to the Target Milestone field
Posted by Marcus <ma...@wtnet.de>.
Am 03/22/2016 12:52 AM, schrieb Pedro Lino:
>> It's not about to draw the line between issues that are resolved and
>> verified solutions. It's about to differentiate issues that are in the real
>> application and therefore need to be fixed in the source code. Here we use
>> (or better should use) RESOLVED - FIXED.
>>
>> But what about issues that are also reporting a problem but the solution
>> (if there is any) is somewhere else? RESOLVED - FIXED doesn't fit, RESOLVED
>> - NOT_AN_ISSUE also not.
>>
>
> Why not use the same nomenclature as the "sibling project"? RESOLVED -
> NOTOURBUG
in general it's OK to look for other projects how they handle such
problems. But NOTOURBUG sounds really ignorant and a bit offensive - at
east in my ears. When I think about the users that reporting such issues
and mostly they think it's important because they cannot go on with
their work, then they deserve a more meaningful status name.
Dennis has made a good suggestion where I'll go on with answering.
> I believe Apache QA needs a flowchart such as
> https://wiki.documentfoundation.org/images/c/c4/Unconfirmed_Bugs_Status_Flowchart_Version_0.1.pdf
> https://wiki.documentfoundation.org/images/c/cb/Unconfirmed_Bugs_Status_Flowchart.odg
I'm pretty sure we have a similar flow chart somewhere in the depths of
our Wiki. But yes, in general this would help to understand how the
issue statuses are working together.
Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Can we add the value "N/A" to the Target Milestone field
Posted by Pedro Lino <pe...@gmail.com>.
> It's not about to draw the line between issues that are resolved and
> verified solutions. It's about to differentiate issues that are in the real
> application and therefore need to be fixed in the source code. Here we use
> (or better should use) RESOLVED - FIXED.
>
> But what about issues that are also reporting a problem but the solution
> (if there is any) is somewhere else? RESOLVED - FIXED doesn't fit, RESOLVED
> - NOT_AN_ISSUE also not.
>
Why not use the same nomenclature as the "sibling project"? RESOLVED -
NOTOURBUG
I believe Apache QA needs a flowchart such as
https://wiki.documentfoundation.org/images/c/c4/Unconfirmed_Bugs_Status_Flowchart_Version_0.1.pdf
https://wiki.documentfoundation.org/images/c/cb/Unconfirmed_Bugs_Status_Flowchart.odg
Re: Can we add the value "N/A" to the Target Milestone field
Posted by Marcus <ma...@wtnet.de>.
Am 03/22/2016 12:30 AM, schrieb Pedro Lino:
> On Mon, Mar 21, 2016 at 10:32 PM, Marcus<ma...@wtnet.de> wrote:
>
>> 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.
>>
>
> There is already a final status after RESOLVED - FIXED. It's VERIFIED -
> FIXED. It is set after a QA member verifies that the fix actually solved
> the problem and that it does not occur in the RC.
>
> Hope this helps.
no, that's not what I meant. ;-)
It's not about to draw the line between issues that are resolved and
verified solutions. It's about to differentiate issues that are in the
real application and therefore need to be fixed in the source code. Here
we use (or better should use) RESOLVED - FIXED.
But what about issues that are also reporting a problem but the solution
(if there is any) is somewhere else? RESOLVED - FIXED doesn't fit,
RESOLVED - NOT_AN_ISSUE also not.
Therefore I suggested a new status RESOLVED - RESOLVED.
I hope this explains it better.
Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Can we add the value "N/A" to the Target Milestone field
Posted by Marcus <ma...@wtnet.de>.
Am 03/22/2016 12:30 AM, schrieb Pedro Lino:
> On Mon, Mar 21, 2016 at 10:32 PM, Marcus<ma...@wtnet.de> wrote:
>
>> 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.
>>
>
> There is already a final status after RESOLVED - FIXED. It's VERIFIED -
> FIXED. It is set after a QA member verifies that the fix actually solved
> the problem and that it does not occur in the RC.
>
> Hope this helps.
no, that's not what I meant. ;-)
It's not about to draw the line between issues that are resolved and
verified solutions. It's about to differentiate issues that are in the
real application and therefore need to be fixed in the source code. Here
we use (or better should use) RESOLVED - FIXED.
But what about issues that are also reporting a problem but the solution
(if there is any) is somewhere else? RESOLVED - FIXED doesn't fit,
RESOLVED - NOT_AN_ISSUE also not.
Therefore I suggested a new status RESOLVED - RESOLVED.
I hope this explains it better.
Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
For additional commands, e-mail: qa-help@openoffice.apache.org
Re: Can we add the value "N/A" to the Target Milestone field
Posted by Pedro Lino <pe...@gmail.com>.
On Mon, Mar 21, 2016 at 10:32 PM, Marcus <ma...@wtnet.de> wrote:
> 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.
>
There is already a final status after RESOLVED - FIXED. It's VERIFIED -
FIXED. It is set after a QA member verifies that the fix actually solved
the problem and that it does not occur in the RC.
Hope this helps.
Re: Can we add the value "N/A" to the Target Milestone field
Posted by Pedro Lino <pe...@gmail.com>.
On Mon, Mar 21, 2016 at 10:32 PM, Marcus <ma...@wtnet.de> wrote:
> 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.
>
There is already a final status after RESOLVED - FIXED. It's VERIFIED -
FIXED. It is set after a QA member verifies that the fix actually solved
the problem and that it does not occur in the RC.
Hope this helps.
Re: Can we add the value "N/A" to the Target Milestone field
Posted by Marcus <ma...@wtnet.de>.
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:pats@acm.org] Sent: Monday, March 21, 2016
>>> 09:10 To: dev@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.hamilton@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: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Can we add the value "N/A" to the Target Milestone field
Posted by Marcus <ma...@wtnet.de>.
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:pats@acm.org] Sent: Monday, March 21, 2016
>>> 09:10 To: dev@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.hamilton@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-unsubscribe@openoffice.apache.org
For additional commands, e-mail: qa-help@openoffice.apache.org
Re: Can we add the value "N/A" to the Target Milestone field
Posted by Kay Schenk <ka...@gmail.com>.
[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:pats@acm.org] Sent: Monday, March 21, 2016
>> 09:10 To: dev@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.hamilton@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-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail:
>> dev-help@openoffice.apache.org
>
>
> ---------------------------------------------------------------------
>
>
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail:
> dev-help@openoffice.apache.org
>
--
--------------------------------------------
MzK
"Time spent with cats is never wasted."
-- Sigmund Freud
---------------------------------------------------------------------
To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
For additional commands, e-mail: qa-help@openoffice.apache.org
Re: Can we add the value "N/A" to the Target Milestone field
Posted by Kay Schenk <ka...@gmail.com>.
[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:pats@acm.org] Sent: Monday, March 21, 2016
>> 09:10 To: dev@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.hamilton@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-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail:
>> dev-help@openoffice.apache.org
>
>
> ---------------------------------------------------------------------
>
>
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail:
> dev-help@openoffice.apache.org
>
--
--------------------------------------------
MzK
"Time spent with cats is never wasted."
-- Sigmund Freud
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
RE: Can we add the value "N/A" to the Target Milestone field
Posted by "Dennis E. Hamilton" <de...@acm.org>.
> -----Original Message-----
> From: Patricia Shanahan [mailto:pats@acm.org]
> Sent: Monday, March 21, 2016 09:10
> To: dev@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.hamilton@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-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Can we add the value "N/A" to the Target Milestone field
Posted by Marcus <ma...@wtnet.de>.
Am 03/21/2016 05:10 PM, schrieb Patricia Shanahan:
> On 3/21/2016 8:59 AM, Kay Schenk wrote:
>> On Sun, Mar 20, 2016 at 3:46 PM, Dennis E. Hamilton
>> <dennis.hamilton@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.
>>
>> 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?
no real objection, just the fact there is no other status available to
indicate that the issue was resolved successfully. ;-)
> 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?
Hm, no. NOT_AN_ISSUE is also not correct as actually it was solved. But
not in the code. So, I would suggest another status to reflect this
(e.g., RESOLVED - resolved).
But it's OK to set the target to a value other that a version number to
make it really visible.
Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Can we add the value "N/A" to the Target Milestone field
Posted by Patricia Shanahan <pa...@acm.org>.
On 3/21/2016 8:59 AM, Kay Schenk wrote:
> On Sun, Mar 20, 2016 at 3:46 PM, Dennis E. Hamilton <dennis.hamilton@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.
>
> 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?
Patricia
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Fwd: Can we add the value "N/A" to the Target Milestone field
Posted by Kay Schenk <ka...@gmail.com>.
Forgot to copy qa on my reply.
---------- Forwarded message ----------
From: Kay Schenk <ka...@gmail.com>
Date: Mon, Mar 21, 2016 at 8:59 AM
Subject: Re: Can we add the value "N/A" to the Target Milestone field
To: OOo Apache <de...@openoffice.apache.org>, Dennis Hamilton <
dennis.hamilton@acm.org>
On Sun, Mar 20, 2016 at 3:46 PM, Dennis E. Hamilton <dennis.hamilton@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.
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.
>
> In those cases, it is preferable to change the resolution.
>
> > -----Original Message-----
> > From: Andrea Pescetti [mailto:pescetti@apache.org]
> > Sent: Sunday, March 20, 2016 14:09
> > To: qa@openoffice.apache.org; dev@openoffice.apache.org
> > Subject: Re: Can we add the value "N/A" to the Target Milestone field
> >
> > Kay Schenk wrote:
> > > We seem to have a number of issues in BZ that are now listed
> > > as Resolved/Fixed but don't seem to pertain to an actual
> > > upcoming release.
> >
> > Everything that was marked RESOLVED FIXED will be in 4.2.0. So 4.2.0 is
> > a perfectly valid value for these cases.
> >
> > Just to be clear: 4.1.2 was a maintenance release and issues had to be
> > approved as release blockers in that case. 4.2.0 will be a normal
> > release, made from trunk, so everything that is on trunk (untile a
> > certain moment when we will decide to branch) will be into it
> > automatically. So the target is 4.2.0 in those cases.
> >
> > Regards,
> > Andrea.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
> > For additional commands, e-mail: qa-help@openoffice.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
--
----------------------------------------------------------------------
MzK
"Time spent with cats is never wasted."
-- Sigmund Freud
--
----------------------------------------------------------------------
MzK
"Time spent with cats is never wasted."
-- Sigmund Freud
Re: Can we add the value "N/A" to the Target Milestone field
Posted by Carl Marcum <cm...@apache.org>.
On 03/21/2016 10:37 PM, Dennis E. Hamilton wrote:
>
>> -----Original Message-----
>> From: Carl Marcum [mailto:cmarcum@apache.org]
>> Sent: Monday, March 21, 2016 15:30
>> To: dev@openoffice.apache.org
>> Subject: Re: Can we add the value "N/A" to the Target Milestone field
>>
> [ ... ]
>>
>> I have been guilty of creating issues for coding tasks because I like
>> to see SVN commits that are tied to an issue.
>>
>> Examples could be an update to the netbeans plugin or adding the
>> bootstrap-connector to SVN, etc.
>>
>> I think Resolved - Not an issue is most appropriate in these cases.
>>
>> I never really asked if this is done by others.
>>
>> Is this procedure used by others?
> [orcmid]
>
> Carl, that is an admirable way to use the BZ. You can always make tasks instead of defect reports, or even treat them as enhancements you are accepting and processing yourself.
>
> I think you can use Resolved Fixed when you have the code in the SVN, just tie them to AOO Release None (unless we come up with separate release identifiers for UnoTools, something that would matter if someone submitted bugs or feature requests from elsewhere).
>
> We don't have very many completion codes. Fixed is the closest to "Done" that I think we have.
>
> When the code is released, you can close the issue.
>
>
>
Dennis,
Thanks for the feedback.
Carl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
RE: Can we add the value "N/A" to the Target Milestone field
Posted by "Dennis E. Hamilton" <de...@acm.org>.
> -----Original Message-----
> From: Carl Marcum [mailto:cmarcum@apache.org]
> Sent: Monday, March 21, 2016 15:30
> To: dev@openoffice.apache.org
> Subject: Re: Can we add the value "N/A" to the Target Milestone field
>
[ ... ]
>
>
> I have been guilty of creating issues for coding tasks because I like
> to see SVN commits that are tied to an issue.
>
> Examples could be an update to the netbeans plugin or adding the
> bootstrap-connector to SVN, etc.
>
> I think Resolved - Not an issue is most appropriate in these cases.
>
> I never really asked if this is done by others.
>
> Is this procedure used by others?
[orcmid]
Carl, that is an admirable way to use the BZ. You can always make tasks instead of defect reports, or even treat them as enhancements you are accepting and processing yourself.
I think you can use Resolved Fixed when you have the code in the SVN, just tie them to AOO Release None (unless we come up with separate release identifiers for UnoTools, something that would matter if someone submitted bugs or feature requests from elsewhere).
We don't have very many completion codes. Fixed is the closest to "Done" that I think we have.
When the code is released, you can close the issue.
>
> Thanks,
> Carl
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Can we add the value "N/A" to the Target Milestone field
Posted by Carl Marcum <cm...@apache.org>.
On 03/21/2016 03:05 PM, Dennis E. Hamilton wrote:
>
>> -----Original Message-----
>> From: Keith N. McKenna [mailto:keith.mckenna@comcast.net]
>> Sent: Monday, March 21, 2016 10:22
>> To: dev@openoffice.apache.org
>> Subject: Re: Can we add the value "N/A" to the Target Milestone field
>>
>> Kay Schenk wrote:
> [ ... ]
>>> The problem is stemming from the use of BZ as both a code centric
>> problem
>>> reporting mechanism and a user support tool.
>>>
>> You are right on that. Historically Bugzilla was used strictly to track
>> items that were issues with the OpenOffice software itself, and not for
>> use as a user support venue. That is why we had and still have the
>> support forums and the user mailing list. IMHO it is perfectly correct
>> to to use Resolved-Not An Issue to close purely support issues.
>>
>> Keith
> [orcmid]
>
> I have already remarked that I think this separation is too binary. These are often not "purely support" matters and the mailing lists are often not that helpful. The forums are great when an issue is curated so that users don't have to parse all the comments to figure out what's-what.
>
> One thing the BZ does, if someone has figured out how to make a report, is provide issue-specific mailings of comments back to the reporter, and that's automatic.
>
> Also, my view is that every BZ issue (and reports on lists and the forums) is a gift. Someone went to a fair amount of difficulty to make their experience known. We should be grateful and that should be reflected in responses. Users are completely baffled by "NOT AN ISSUE" when that is patently untrue in their world and I doubt it reflects well on the project.
>
> Sometimes users, based on provided comments, will figure out that it may be something they did and can avoid, or there is a feature that solves their problem. That's great, and the issue will not stick around and look like an open matter. This is not the norm. Even so, these tell us things where we might have something more helpful in place for fielding a particular case in the future.
>
>
>>>> In those cases, it is preferable to change the resolution.
>>>>
>>>>> -----Original Message-----
>>>>> From: Andrea Pescetti [mailto:pescetti@apache.org]
>>>>> Sent: Sunday, March 20, 2016 14:09
>>>>> To: qa@openoffice.apache.org; dev@openoffice.apache.org
>>>>> Subject: Re: Can we add the value "N/A" to the Target Milestone
>> field
>>>>> Kay Schenk wrote:
>>>>>> We seem to have a number of issues in BZ that are now listed
>>>>>> as Resolved/Fixed but don't seem to pertain to an actual
>>>>>> upcoming release.
>>>>> Everything that was marked RESOLVED FIXED will be in 4.2.0. So 4.2.0
>> is
>>>>> a perfectly valid value for these cases.
>>>>>
>>>>> Just to be clear: 4.1.2 was a maintenance release and issues had to
>> be
>>>>> approved as release blockers in that case. 4.2.0 will be a normal
>>>>> release, made from trunk, so everything that is on trunk (untile a
>>>>> certain moment when we will decide to branch) will be into it
>>>>> automatically. So the target is 4.2.0 in those cases.
>>>>>
>>>>> Regards,
>>>>> Andrea.
>>>>>
>>>>> --------------------------------------------------------------------
>>>>>
I have been guilty of creating issues for coding tasks because I like
to see SVN commits that are tied to an issue.
Examples could be an update to the netbeans plugin or adding the
bootstrap-connector to SVN, etc.
I think Resolved - Not an issue is most appropriate in these cases.
I never really asked if this is done by others.
Is this procedure used by others?
Thanks,
Carl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
RE: Can we add the value "N/A" to the Target Milestone field
Posted by "Dennis E. Hamilton" <de...@acm.org>.
> -----Original Message-----
> From: Keith N. McKenna [mailto:keith.mckenna@comcast.net]
> Sent: Monday, March 21, 2016 10:22
> To: dev@openoffice.apache.org
> Subject: Re: Can we add the value "N/A" to the Target Milestone field
>
> Kay Schenk wrote:
[ ... ]
> > The problem is stemming from the use of BZ as both a code centric
> problem
> > reporting mechanism and a user support tool.
> >
>
> You are right on that. Historically Bugzilla was used strictly to track
> items that were issues with the OpenOffice software itself, and not for
> use as a user support venue. That is why we had and still have the
> support forums and the user mailing list. IMHO it is perfectly correct
> to to use Resolved-Not An Issue to close purely support issues.
>
> Keith
[orcmid]
I have already remarked that I think this separation is too binary. These are often not "purely support" matters and the mailing lists are often not that helpful. The forums are great when an issue is curated so that users don't have to parse all the comments to figure out what's-what.
One thing the BZ does, if someone has figured out how to make a report, is provide issue-specific mailings of comments back to the reporter, and that's automatic.
Also, my view is that every BZ issue (and reports on lists and the forums) is a gift. Someone went to a fair amount of difficulty to make their experience known. We should be grateful and that should be reflected in responses. Users are completely baffled by "NOT AN ISSUE" when that is patently untrue in their world and I doubt it reflects well on the project.
Sometimes users, based on provided comments, will figure out that it may be something they did and can avoid, or there is a feature that solves their problem. That's great, and the issue will not stick around and look like an open matter. This is not the norm. Even so, these tell us things where we might have something more helpful in place for fielding a particular case in the future.
> >
> >>
> >> In those cases, it is preferable to change the resolution.
> >>
> >>> -----Original Message-----
> >>> From: Andrea Pescetti [mailto:pescetti@apache.org]
> >>> Sent: Sunday, March 20, 2016 14:09
> >>> To: qa@openoffice.apache.org; dev@openoffice.apache.org
> >>> Subject: Re: Can we add the value "N/A" to the Target Milestone
> field
> >>>
> >>> Kay Schenk wrote:
> >>>> We seem to have a number of issues in BZ that are now listed
> >>>> as Resolved/Fixed but don't seem to pertain to an actual
> >>>> upcoming release.
> >>>
> >>> Everything that was marked RESOLVED FIXED will be in 4.2.0. So 4.2.0
> is
> >>> a perfectly valid value for these cases.
> >>>
> >>> Just to be clear: 4.1.2 was a maintenance release and issues had to
> be
> >>> approved as release blockers in that case. 4.2.0 will be a normal
> >>> release, made from trunk, so everything that is on trunk (untile a
> >>> certain moment when we will decide to branch) will be into it
> >>> automatically. So the target is 4.2.0 in those cases.
> >>>
> >>> Regards,
> >>> Andrea.
> >>>
> >>> --------------------------------------------------------------------
> -
> >>> To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
> >>> For additional commands, e-mail: qa-help@openoffice.apache.org
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> >> For additional commands, e-mail: dev-help@openoffice.apache.org
> >>
> >>
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Can we add the value "N/A" to the Target Milestone field
Posted by "Keith N. McKenna" <ke...@comcast.net>.
Kay Schenk wrote:
> On Sun, Mar 20, 2016 at 3:46 PM, Dennis E. Hamilton <dennis.hamilton@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.
>
Kay, what you had been doing I believe is the right approach to take for
the use of Resolved-Fixed. It means that there was a problem with our
software that was fixed and committed to SVN and is available for the
next appropriate level of Release.
> 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.
>
You are right on that. Historically Bugzilla was used strictly to track
items that were issues with the OpenOffice software itself, and not for
use as a user support venue. That is why we had and still have the
support forums and the user mailing list. IMHO it is perfectly correct
to to use Resolved-Not An Issue to close purely support issues.
Keith
>
>>
>> In those cases, it is preferable to change the resolution.
>>
>>> -----Original Message-----
>>> From: Andrea Pescetti [mailto:pescetti@apache.org]
>>> Sent: Sunday, March 20, 2016 14:09
>>> To: qa@openoffice.apache.org; dev@openoffice.apache.org
>>> Subject: Re: Can we add the value "N/A" to the Target Milestone field
>>>
>>> Kay Schenk wrote:
>>>> We seem to have a number of issues in BZ that are now listed
>>>> as Resolved/Fixed but don't seem to pertain to an actual
>>>> upcoming release.
>>>
>>> Everything that was marked RESOLVED FIXED will be in 4.2.0. So 4.2.0 is
>>> a perfectly valid value for these cases.
>>>
>>> Just to be clear: 4.1.2 was a maintenance release and issues had to be
>>> approved as release blockers in that case. 4.2.0 will be a normal
>>> release, made from trunk, so everything that is on trunk (untile a
>>> certain moment when we will decide to branch) will be into it
>>> automatically. So the target is 4.2.0 in those cases.
>>>
>>> Regards,
>>> Andrea.
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
>>> For additional commands, e-mail: qa-help@openoffice.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>
>>
>
>
Re: Can we add the value "N/A" to the Target Milestone field
Posted by Kay Schenk <ka...@gmail.com>.
On Sun, Mar 20, 2016 at 3:46 PM, Dennis E. Hamilton <dennis.hamilton@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.
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.
>
> In those cases, it is preferable to change the resolution.
>
> > -----Original Message-----
> > From: Andrea Pescetti [mailto:pescetti@apache.org]
> > Sent: Sunday, March 20, 2016 14:09
> > To: qa@openoffice.apache.org; dev@openoffice.apache.org
> > Subject: Re: Can we add the value "N/A" to the Target Milestone field
> >
> > Kay Schenk wrote:
> > > We seem to have a number of issues in BZ that are now listed
> > > as Resolved/Fixed but don't seem to pertain to an actual
> > > upcoming release.
> >
> > Everything that was marked RESOLVED FIXED will be in 4.2.0. So 4.2.0 is
> > a perfectly valid value for these cases.
> >
> > Just to be clear: 4.1.2 was a maintenance release and issues had to be
> > approved as release blockers in that case. 4.2.0 will be a normal
> > release, made from trunk, so everything that is on trunk (untile a
> > certain moment when we will decide to branch) will be into it
> > automatically. So the target is 4.2.0 in those cases.
> >
> > Regards,
> > Andrea.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
> > For additional commands, e-mail: qa-help@openoffice.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
--
----------------------------------------------------------------------
MzK
"Time spent with cats is never wasted."
-- Sigmund Freud
RE: Can we add the value "N/A" to the Target Milestone field
Posted by "Dennis E. Hamilton" <de...@acm.org>.
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?
In those cases, it is preferable to change the resolution.
> -----Original Message-----
> From: Andrea Pescetti [mailto:pescetti@apache.org]
> Sent: Sunday, March 20, 2016 14:09
> To: qa@openoffice.apache.org; dev@openoffice.apache.org
> Subject: Re: Can we add the value "N/A" to the Target Milestone field
>
> Kay Schenk wrote:
> > We seem to have a number of issues in BZ that are now listed
> > as Resolved/Fixed but don't seem to pertain to an actual
> > upcoming release.
>
> Everything that was marked RESOLVED FIXED will be in 4.2.0. So 4.2.0 is
> a perfectly valid value for these cases.
>
> Just to be clear: 4.1.2 was a maintenance release and issues had to be
> approved as release blockers in that case. 4.2.0 will be a normal
> release, made from trunk, so everything that is on trunk (untile a
> certain moment when we will decide to branch) will be into it
> automatically. So the target is 4.2.0 in those cases.
>
> Regards,
> Andrea.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: qa-help@openoffice.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
RE: Can we add the value "N/A" to the Target Milestone field
Posted by "Dennis E. Hamilton" <de...@acm.org>.
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?
In those cases, it is preferable to change the resolution.
> -----Original Message-----
> From: Andrea Pescetti [mailto:pescetti@apache.org]
> Sent: Sunday, March 20, 2016 14:09
> To: qa@openoffice.apache.org; dev@openoffice.apache.org
> Subject: Re: Can we add the value "N/A" to the Target Milestone field
>
> Kay Schenk wrote:
> > We seem to have a number of issues in BZ that are now listed
> > as Resolved/Fixed but don't seem to pertain to an actual
> > upcoming release.
>
> Everything that was marked RESOLVED FIXED will be in 4.2.0. So 4.2.0 is
> a perfectly valid value for these cases.
>
> Just to be clear: 4.1.2 was a maintenance release and issues had to be
> approved as release blockers in that case. 4.2.0 will be a normal
> release, made from trunk, so everything that is on trunk (untile a
> certain moment when we will decide to branch) will be into it
> automatically. So the target is 4.2.0 in those cases.
>
> Regards,
> Andrea.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: qa-help@openoffice.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
For additional commands, e-mail: qa-help@openoffice.apache.org
Re: Can we add the value "N/A" to the Target Milestone field
Posted by Andrea Pescetti <pe...@apache.org>.
Kay Schenk wrote:
> We seem to have a number of issues in BZ that are now listed
> as Resolved/Fixed but don't seem to pertain to an actual
> upcoming release.
Everything that was marked RESOLVED FIXED will be in 4.2.0. So 4.2.0 is
a perfectly valid value for these cases.
Just to be clear: 4.1.2 was a maintenance release and issues had to be
approved as release blockers in that case. 4.2.0 will be a normal
release, made from trunk, so everything that is on trunk (untile a
certain moment when we will decide to branch) will be into it
automatically. So the target is 4.2.0 in those cases.
Regards,
Andrea.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Can we add the value "N/A" to the Target Milestone field
Posted by Marcus <ma...@wtnet.de>.
Am 03/20/2016 09:08 PM, schrieb Kay Schenk:
> We seem to have a number of issues in BZ that are now listed
> as Resolved/Fixed but don't seem to pertain to an actual
> upcoming release.
>
> Examples:
> https://bz.apache.org/ooo/show_bug.cgi?id=126652
> https://bz.apache.org/ooo/show_bug.cgi?id=126828
>
> Can we add something like "N/A" or the like to our Target
> Milestone field rather than the default "--" so we know
> these should never be considered for a release?
sounds reasonable. I've added an "None" to the list of available
milestones for many products (the application modules and related things).
Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Can we add the value "N/A" to the Target Milestone field
Posted by Andrea Pescetti <pe...@apache.org>.
Kay Schenk wrote:
> We seem to have a number of issues in BZ that are now listed
> as Resolved/Fixed but don't seem to pertain to an actual
> upcoming release.
Everything that was marked RESOLVED FIXED will be in 4.2.0. So 4.2.0 is
a perfectly valid value for these cases.
Just to be clear: 4.1.2 was a maintenance release and issues had to be
approved as release blockers in that case. 4.2.0 will be a normal
release, made from trunk, so everything that is on trunk (untile a
certain moment when we will decide to branch) will be into it
automatically. So the target is 4.2.0 in those cases.
Regards,
Andrea.
---------------------------------------------------------------------
To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
For additional commands, e-mail: qa-help@openoffice.apache.org