Web lists-archives.com

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!

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