Re: Improving the Bugzilla Triage Process for Extensions
Andrew Williamson
> Hi AMO-folks,
>
> I apologize for not cross-posting, as I didn't know that this newsgroup
> existed. I'd love to get some AMO eyes on this thread:
>
> http://groups.google.com/group/mozilla.dev.quality/browse_thread/thread/d08a7eeb4203651e#
>
>
> In short this is what I propose:
>
> This is mostly a Firefox problem, but I think that it could apply to any
> Mozilla product that uses AddOns.
>
> We often get users reporting errors into Firefox bugzilla components
> that turn out to be caused by specific add-ons. The current triage
> process is that once we determine that it is an extension problem, we
> advise the reporter to notify the extension developer and we close the
> bug report as "INVALID" (aka, not a Firefox bug).
>
> There are problems with this:
> * We have no way to know if the extension developer is ever actually
> notified.
> * An interested extension developer (or AMO reviewer) has no means to
> query for these bugs and find them as they are scattered across Firefox
> components and its never intuitive that you'd want to query for
> "invalid" bugs.
>
> So I propose we modify the QA triage process as follows:
> * Once a bug is deemed to be caused by extension X, we:
> ** move the bug to Firefox->Extension Compatibility component
> ** Leave the bug in the "NEW" state (is this a good idea?)
> ** Change either the whiteboard or the Summary to indicate this is an [X
> issue] so that the extension name shows up in those tags to make it easy
> to query for specific bugs related to specific extensions.
>
> Do you have thoughts on this? Is there some other process that would
> ensure these sorts of problems don't fall through the cracks? Please
> follow up to m.d.quality.
Moving the bugs to a separate component and putting the addon name in the
summary is sensible.
I don't think developers aren't going to be any more likely to search bugzilla
on a regular basis though, even if under this proposal they would be able to.
So I don't think it will solve the underlying problem unfortunately.
Andrew Williamson
Brian King
> Moving the bugs to a separate component and putting the addon name in
> the summary is sensible.
> I don't think developers aren't going to be any more likely to search
> bugzilla on a regular basis though, even if under this proposal they
> would be able to.
> So I don't think it will solve the underlying problem unfortunately.
Clint, your proposed solution is better than what we have, but I agree
with Andrew that the problem is getting add-on devs to look in Bugzilla.
Most have their own feedback mechanisms in places like Mozdev, Google
Code, and plain ol' email.
One solution might be to put a 'Query bugs' link somewhere in the AMO
Developer Panel that does a bug lookup for their particular add-on, but
that does not cover add-ons not hosted on AMO.
--
Brian King
Need free Mozilla project hosting?
http://mozdev.org
Seth Wagoner
> One solution might be to put a 'Query bugs' link somewhere in the AMO
> Developer Panel that does a bug lookup for their particular add-on, but
> that does not cover add-ons not hosted on AMO.
Sounds good! I would suggest that it could search SUMO and
forums.mozillazine as well as Bugzilla? And if you wanted to get
really fancy, you could always suck in searches on "extension
name"+firefox+bugs|bug|conflicts from other sources using Yahoo BOSS
or the Google Search APIs?
--
Seth Wagoner
http://interclue.com
http://lazarus.interclue.com
Ray Kiddy
Clint Talbert <ctal...@mozilla.com> wrote:
> Hi AMO-folks,
>
> I apologize for not cross-posting, as I didn't know that this newsgroup
> existed. I'd love to get some AMO eyes on this thread:
>
> http://groups.google.com/group/mozilla.dev.quality/browse_thread/thread/d08a7e
> eb4203651e#
>
> In short this is what I propose:
>
> This is mostly a Firefox problem, but I think that it could apply to any
> Mozilla product that uses AddOns.
>
> We often get users reporting errors into Firefox bugzilla components
> that turn out to be caused by specific add-ons. The current triage
> process is that once we determine that it is an extension problem, we
> advise the reporter to notify the extension developer and we close the
> bug report as "INVALID" (aka, not a Firefox bug).
>
> There are problems with this:
> * We have no way to know if the extension developer is ever actually
> notified.
Is there any way at all, in bugzilla, to know if anyone is ever actually
informed of anything? Does the bugzilla, as mozilla uses it, have any
concept of a DRI?
> * An interested extension developer (or AMO reviewer) has no means to
> query for these bugs and find them as they are scattered across Firefox
> components and its never intuitive that you'd want to query for
> "invalid" bugs.
>
See first suggestion, below.
> So I propose we modify the QA triage process as follows:
> * Once a bug is deemed to be caused by extension X, we:
> ** move the bug to Firefox->Extension Compatibility component
Good idea.
> ** Leave the bug in the "NEW" state (is this a good idea?)
Probably a good idea.
> ** Change either the whiteboard or the Summary to indicate this is an [X
> issue] so that the extension name shows up in those tags to make it easy
> to query for specific bugs related to specific extensions.
Makes sense.
>
> Do you have thoughts on this? Is there some other process that would
> ensure these sorts of problems don't fall through the cracks? Please
> follow up to m.d.quality.
How about these?
** Provide support (ie a link) in AMO for find the bugs registered
against their addon. Perhaps there can be a label in the bug that
identifies an addon, such as could be created in the AMO site. Addons in
AMO have an id, yes? There are many ways to do this, eg; [AMO #id] in
the whiteboard, etc, etc.
** Automated testing can be run against FF or other apps with sets of
addons installed. These tests do not have to test the addons. They would
merely test the co-existence of the addons with normal app functionality.
** Developers could be given a place to register automated test cases
which do actually test the functionality of the addon. These could be
run and moco would report the results and could do nothing else. An
addon with a failing test could even be marked so in AMO or removed for
AMO, if that seemed to be justified.
> Thanks,
>
> Clint