On 16.06.2017 22:28, Nate Graham wrote:
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".
If you can reproduce it, you can add the 'reproducible' keyword, or add
a comment, especially if you feel the steps to reproduce are not
described in detail.
For example, I tried to reproduce bug 381265 but could not, either
because I have a different configuration of KRunner plugins or different
Plasma version, or the steps are explained in a way that I did something
different.
I would rather set the state to NEEDSINFO, especially because it lacks a
backtrace.
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!
Nate
On 06/16/2017 01:59 PM, Christoph Feck wrote:
Hi Nate,
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
https://bugs.kde.org/show_bug.cgi?id=375993.
- 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.
Use wisely.
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.
Christoph Feck
KDE Bug Triaging Team
