Re: Bugzilla maintenance work
- Date: Fri, 16 Jun 2017 14:28:31 -0600
- From: Nate Graham <pointedstick@xxxxxxxx>
- Subject: Re: Bugzilla maintenance work
Thank you, Chris.
So I should not mark a bug as CONFIRMED when I or someone else has
simply reproduced it? The most logical meaning to me is that CONFIRMED
means "We've verified that this is a real bug but we don't yet know
what's causing it".
Might it make sense to introduce another state ("INVESTIGATED?") to
describe the state meaning "We've not only verified that this is a real
bug, but we think we know what's causing it, though we haven't been able
to fix it yet."
If not, then that's fine, and I'll go with the existing flow. Thanks again!
On 06/16/2017 01:59 PM, Christoph Feck wrote:
On 16.06.2017 19:24, Nate Graham wrote:
In my past life, I've done a lot of issue tracker and bug management
work, and I'd like to do the same for the KDE bugzilla, where there are
a lot of bugs that are duplicates, untriaged, etc. How can I go about
getting permission to do things like change bug statuses? For example,
I'd like to:
- Mark https://bugs.kde.org/show_bug.cgi?id=374954 as a duplicate of
- Confirm https://bugs.kde.org/show_bug.cgi?id=381265
- Pass back https://bugs.kde.org/show_bug.cgi?id=381269 with NEEDINFO
I have given you rights to change all aspects of a bug.
Note, however, that we use the CONFIRMED state when a developer
investigated the issue, understands the reason for the bug, and
documents it. That's the reason a regular user cannot change the status
to CONFIRMED. A triager or developer (on seeing this state), might
assume someone else already investigated the issue if it was changed
without the proper investigation.
The type of confirmation the user wants to see is simply the fact that
the bug is open. If it was not a bug to begin with, or was investigated
to be caused by a bug outside our software, it will be clossed.
KDE Bug Triaging Team