Appropriate for me to assign a bug?

0 views
Skip to first unread message

Jake

unread,
Oct 10, 2006, 1:29:37 PM10/10/06
to
I have just gotten permission to confirm bugs, so I am still learning
the appropriate ways to do things so I don't make mistakes.

I don't understand why confirmed bugs are assigned to
nob...@mozilla.org. Shouldn't all confirmed bugs be automatically
assigned to the default component owner? When is it appropriate for me
to click the "Reassign bug to default assignee and QA contact of
selected component" radio button?

Boris Zbarsky

unread,
Oct 10, 2006, 3:09:06 PM10/10/06
to
Jake wrote:
> I don't understand why confirmed bugs are assigned to
> nob...@mozilla.org.

This actually depends on the component. Many components have nob...@mozilla.org
as component owner because that accurately reflects the state of whether anyone
is working on a bug.

> Shouldn't all confirmed bugs be automatically
> assigned to the default component owner?

All filed bugs are assigned to the default component owner. Again, for most
components this is nob...@mozilla.org.

> When is it appropriate for me
> to click the "Reassign bug to default assignee and QA contact of
> selected component" radio button?

Any time you're changing the component and the current assignee is the default
assignee (and the current QA contact is the default QA contact, but I can't
think of cases when it isn't).

-Boris

Adam Guthrie

unread,
Oct 11, 2006, 12:50:07 AM10/11/06
to
Hi Jake,

I've noticed that you're verifying a lot of bugs. Personally, I'm not a
big fan of verifying bugs unless it's shortly after they've been fixed,
and that it's easily verifiable. This is mainly because it generates
unneeded "bugspam" that's annoying to have to trudge through.

When you verify these bugs are you checking to see yourself that they've
been fixed? This entails repeating the steps to reproduce and making
sure that you don't see the bug.

As for verifying duplicates, I am mostly against this as well. If you
read a bug after it's been duped and strongly agree that it's a dupe,
OK, verify it, but please don't go finding old dupes just to verify them.

Also, if you verify that a bug has been fixed on the 1.8 branch (Firefox
2), please replace the fixed1.8.1 keyword with verified1.8.1.

That said, I think your time would be better spent QAing unconfirmed
bugs. Those are the ones that really need our attention.

Thanks for your help volunteering, and I hope you take this advice into
consideration when triaging. Also, please feel free to join #qa on
irc.mozilla.org and ask any questions that you might have.

Regards,
Adam

Dave Liebreich

unread,
Oct 11, 2006, 8:24:13 AM10/11/06
to
Adam Guthrie wrote:

> When you verify these bugs are you checking to see yourself that they've
> been fixed? This entails repeating the steps to reproduce and making
> sure that you don't see the bug.

I think verifying bugs can be a good thing to do, even if the bugs are old.

If I were to go through old bugs like this, I would make sure I could
reproduce the original problem, on my system, with an old build. Then I
would install a recent build and repeat the test. If the problem no
longer occurred, and I did not notice any unintended side effects, then
I would go ahead and mark the bug as verified.

The important thing here is to reproduce the problem on my system. On
more than just my system, if possible.

> As for verifying duplicates, I am mostly against this as well. If you
> read a bug after it's been duped and strongly agree that it's a dupe,
> OK, verify it, but please don't go finding old dupes just to verify them.

Again, I think this can be valuable, especially if the other bug has
been fixed. Some bugs are marked as dupes even though the steps to
reproduce are not exactly the same. In that case, I'd go through the
"reproduce the problem"-"install newer build"-"try to reproduce the
problem" cycle before makring the dupe as verified.

> That said, I think your time would be better spent QAing unconfirmed
> bugs. Those are the ones that really need our attention.

Finding a resolved bug that should be reopened would also be valuable.
So is checking that a set of fixed bugs are still fixed. I think there
is room for this activity, too.

> Thanks for your help volunteering, and I hope you take this advice into
> consideration when triaging. Also, please feel free to join #qa on
> irc.mozilla.org and ask any questions that you might have.

+1

-Dave

--
Dave Liebreich
Test Architect, Mozilla Corporation

Justin Wood (Callek)

unread,
Oct 13, 2006, 2:55:42 AM10/13/06
to
Dave Liebreich wrote:

> Adam Guthrie wrote:
>> That said, I think your time would be better spent QAing unconfirmed
>> bugs. Those are the ones that really need our attention.
>
> Finding a resolved bug that should be reopened would also be valuable.
> So is checking that a set of fixed bugs are still fixed. I think there
> is room for this activity, too.
>

IMO, depending on if the resolved bug is new or "old", (which really
depends on the code in question), this might be worth it.

In most cases filing a new bug, similar summary but with c#0 referencing
the bug which 'broke' (and adding a comment in the bug that broke about
the newly filed version) is better. and more likely to get more eyes...

flag it as a regression, and try to find what bug/checkin regressed it.

The original bug was not a regression, but if the original was really
fixed, and its not fixed anymore, then well, the "new" bug (which has
the same symptoms as the old one) is a regression.

>> Thanks for your help volunteering, and I hope you take this advice into
>> consideration when triaging. Also, please feel free to join #qa on
>> irc.mozilla.org and ask any questions that you might have.
>
> +1
>

+2

~Justin Wood (Callek)

Jake

unread,
Oct 15, 2006, 5:02:29 PM10/15/06
to
Another question I've been having is how can I look up someone and see
who they are? When I am reading a comment, it would be very helpful to
know if the commenter is just a triager like me, a developer or just a
random person.

Also, if I am not on the CC list and someone doesnt post a comment when
the change a bug, how can I see what has been changed on a bug that I
am monitoring?

Stefan Sitter

unread,
Oct 15, 2006, 5:13:57 PM10/15/06
to
Jake wrote:
> Also, if I am not on the CC list and someone doesnt post a
> comment when the change a bug, how can I see what has been
> changed on a bug that I am monitoring?

Use the 'View Bug Activity' link.

/Stefan

Nickolay Ponomarev

unread,
Oct 15, 2006, 6:07:27 PM10/15/06
to Jake, dev-q...@lists.mozilla.org
On 15 Oct 2006 14:02:29 -0700, Jake <off...@gmail.com> wrote:
> Another question I've been having is how can I look up someone and see
> who they are? When I am reading a comment, it would be very helpful to
> know if the commenter is just a triager like me, a developer or just a
> random person.
>
You'll know that after a while. For now, you can ask bugzilla (by
looking at bugs he reported and bugs assigned to his account), firebot
on IRC (/msg firebot <nickname>) or ask someone else you know.

Nickolay

Reply all
Reply to author
Forward
0 new messages