DevHeads.net

Bugzilla maintenance work

Hello everyone!

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 <a href="https://bugs.kde.org/show_bug.cgi?id=374954" title="https://bugs.kde.org/show_bug.cgi?id=374954">https://bugs.kde.org/show_bug.cgi?id=374954</a> as a duplicate of
<a href="https://bugs.kde.org/show_bug.cgi?id=375993" title="https://bugs.kde.org/show_bug.cgi?id=375993">https://bugs.kde.org/show_bug.cgi?id=375993</a>.

- Confirm <a href="https://bugs.kde.org/show_bug.cgi?id=381265" title="https://bugs.kde.org/show_bug.cgi?id=381265">https://bugs.kde.org/show_bug.cgi?id=381265</a>

- Pass back <a href="https://bugs.kde.org/show_bug.cgi?id=381269" title="https://bugs.kde.org/show_bug.cgi?id=381269">https://bugs.kde.org/show_bug.cgi?id=381269</a> with NEEDINFO

Etc.

Nate

Comments

Re: Bugzilla maintenance work

By Christoph Feck at 06/16/2017 - 14:59

Hi Nate,

On 16.06.2017 19:24, Nate Graham wrote:
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

Re: Bugzilla maintenance work

By Myriam Schweingruber at 06/19/2017 - 06:06

Hi all,

On Fri, Jun 16, 2017 at 9:59 PM, Christoph Feck < ... at kde dot org> wrote:
Sorry to chime in late, but for completion's sake, please have a look
at our Community wiki for a few guidelines:
<a href="https://community.kde.org/Guidelines_and_HOWTOs/Debugging" title="https://community.kde.org/Guidelines_and_HOWTOs/Debugging">https://community.kde.org/Guidelines_and_HOWTOs/Debugging</a>

As a bug triager and non-developer, I only confirm bugs I can
reproduce myself, and which have clear steps on how to reproduce a
bug, and/or have been confirmed by more than one user. Sadly there are
plenty of reports that lack these steps, so most of the time I have to
ask for more information (and set the status to NEEDSINFO, so it is
easy to search) which I investigate on a regular basis and close them
if there is no feedback within a reasonable time (with our fast paced
development, reasonable in my book is not exceeding 6 weeks, taking
into account holiday breaks of the OR). I then close all those still
missing information as invalid with the mention that we gladly reopen
the bug if the missing information is provided.

Nice to have you on board, Nate :-)

Regards, Myriam

Re: Bugzilla maintenance work

By Nate Graham at 06/16/2017 - 15:28

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:

Re: Bugzilla maintenance work

By Christoph Feck at 06/16/2017 - 15:38

On 16.06.2017 22:28, Nate Graham wrote:
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.

Re: Bugzilla maintenance work

By Nate Graham at 06/16/2017 - 17:34

On 06/16/2017 02:38 PM, Christoph Feck wrote:
FWIW, I can reproduce it 100% with the following exact sequence of
keypresses:

Alt+space
= key
F key
2 key
[crash]

No backtrace is generated, though, either on the console or via drkonqi.
What could be up with that?

Nate

Re: Bugzilla maintenance work

By Nate Graham at 06/16/2017 - 19:43

On 06/16/2017 04:34 PM, Nate Graham wrote:
Never mind, I got a backtrace and updated the bug. Can you reproduce it
by typing "=F2"? Note: the F must be capitalized. "=f2" doesn't do it
for me.

Nate

Re: Bugzilla maintenance work

By Luigi Toscano at 06/16/2017 - 15:35

Nate Graham ha scritto:
It depends on the someone else: another developer or triager can mark it as
CONFIRMED when the bug is really existing. The procedure for becoming a
regular contributor (developer or triager) is always the same: get involved
with the project until someone says "why don't you have the permissions to do
this instead of asking me every time" and you get the permissions :)

I don't see the reason for another state. If it arrives at the point that it's
investigated, it should be moved to CONFIRMED.

Please note that this is my experience with triaging in my non-KDE work time,
so Christopher may disagree with something I wrote above. I'm not doing much
general triaging unfortunately here but with my developer permissions I can
consistently reproduce a bug in some component on bugs.kde.org where I'm not a
regular contributor, I move it to CONFIRMED nevertheless.

Ciao