<a class="header-button" href="https://bugzilla.mozilla.org/home" title="Go to home page"> Bugzilla

Updated

•

18 years ago

Status: NEW → RESOLVED

Closed: 18 years ago

Resolution: --- → DUPLICATE

Reporter

Comment 3

•

18 years ago

From the discussion at bug 339159, this is not a duplicate. 339159 is about reporting problems with add-ons used with products not yet formally released to end users, specifically with nightly builds. This, however, is about reporting problems with add-ons themselves. Obviously, the bug reports should involve only products that are indeed released to end users. This is a facility that already works (apparently well) with Mozdev extensions. Why can it not work with addons.mozilla.org add-ons? Like the Mozdev facility, this should be in a separate installation of Bugzilla with a separate bug database, unlike bug 339159 which seemed to indicate integrating the add-on bugs with the standard bugzilla.mozilla.org implementation and database.

Status: RESOLVED → REOPENED

Resolution: DUPLICATE → ---

Comment 4

•

17 years ago

We have an "add-ons" component here in Bugzilla meanwhile that has had multiple specific Add-ons issues field against it already.

Status: REOPENED → RESOLVED

Closed: 18 years ago → 17 years ago

Resolution: --- → FIXED

Reporter

Comment 5

•

17 years ago

The addons.mozzila.org Product in Bugzilla is for reporting problems with the management of add-ons. There are no Components for reporting problems with specific add-ons. Reopening. Note: If you feel that addons.mozzila.org (or any other exiting Product) is indeed the correct place to report a bug against a specific add-on, please indicate the Classification, Product, and Component I would indicate to report a bug against (for example) Signature Switch (a Thunderbird add-on). The Classification, Product, and Component should be items already within the Bugzilla repertoire.

Status: RESOLVED → REOPENED

Resolution: FIXED → ---

Comment 6

•

17 years ago

Are the bugs 424592, 424723, 424012, 423784 (etc.) examples of what you are asking for?

Reporter

Comment 7

•

17 years ago

Those bugs might be. However, there are no Components for Greasemonkey, Yahoo Toolbar, Glubble Family, etc. Thus, unless you know for what add-ons bug reports have been submitted (with the name of the add-on accurately included in the description), you can't easily construct a Bugzilla query to find all the bugs for a given add-on. During the pending restructuring of Bugzilla (see <http://www.gerv.net/temp/bmo-reorg.html>), there should be a Product for add-ons with a Component for each add-on. This should be for bugs within add-ons, not for bugs relating to the management of add-ons. The two need to be separated.

Basil Hashem [:baz]

Comment 8

•

17 years ago

David, creating 5000 components (approximate count of add-ons and themes hosted on AMO) in bugzilla is not a manageable solution. I suggest we wait for the re-org. Any other suggestions we can consider in the meantime?

:Gavin Sharp [email: gavin@gavinsharp.com]

Reporter

Comment 9

•

17 years ago

I definitely agree that this should wait until the Bugzilla reorganization. there is no point in implementing this now and then having to redo it for the reorg. Looking at the proposed reorg at <http://www.gerv.net/temp/bmo-reorg.html>, the issue is that [Server Software > addons.mozilla.org] should be reserved for bugs relating to the administration of addons.mozilla.org and not for bugs reporting errors in specific add-ons. The latter should be somewhere (not defined in the proposed reorg) under either Client Software or Other [renamed from Client Support]. After all, add-ons are indeed client software but also "other"; they are definitely not servers. No, I don't want to see 5,000 components. Some form of add-on categorization is needed, with the categories being the components.

Comment 10

•

17 years ago

I don't think putting addon bug reports in this instance of Bugzilla is a good idea. It's just going to lead to confusion and be a pain to manage given the large number of addons, and without buy-in from the addon authors themselves it's unlikely to be useful. I think you should focus on finding a separate bugzilla install specifically for Mozilla addons, and let addon authors take the initiative of setting it up if they're ready to accept bug reports through it.

Reporter

Comment 11

•

17 years ago

I agree with comment #10 with respect to a separate Bugzilla installation. This already works with Mozdev extensions, and that's why I suggested it in the original description. As for whether authors of items within addons.mozilla.org will actually "buy in" and respond to bug reports, responsiveness should be a requirement for any new addons before they can even be placed in the "sandbox". This should also be a requirement levied on the authors of existing addons before they can submit updates. The Mozilla organization effectively controls addons.mozilla.org and can thus mandate such requirements.

Comment 12

•

17 years ago

(In reply to comment #11) > I agree with comment #10 with respect to a separate Bugzilla installation. > This already works with Mozdev extensions, and that's why I suggested it in the > original description. > Mozdev is a project hosting repository for extensions, which should indeed provide bug reporting services. addons.mozilla.org is a distribution site for add-ons, and currently has no plans to become a project hosting service. For comparison, think of Facebook apps, Wordpress plugins and themes, iPhone apps, and other product extension repository sites, none of which have bug reporting or hosting services that I can think of. I don't see this as something within the scope of AMO now or in the forseeable future. I think this is WONTFIX.

Comment 13

•

17 years ago

I agree with Justin that for the current scope of AMO, this is a WONTFIX. If at some point in time, the AMO project scope will be redefined to include project hosting, this is something to pick up again. But for now, it's not. Adding a bug tracker would also only be half as good as actually hosting their project on mozdev or sourceforge or wherever, as we currently lack all these other tools (version control etc.) that should integrate nicely with the bug tracking tool. Another question is: What do we do with all the bugs in the Add-on component, mostly mem leaks in different extensions? Unless we want to point these out to the authors, I am quite sure they won't look at them and they'll stay in bugzilla forever.

Basil Hashem [:baz]

Comment 14

•

17 years ago

Agree that AMO shouldn't host bugs for add-ons - authors may have other systems in place for tracking their support issues. We should encourage them to host on MozDev if they don't have such a system. As for "Product: AMO, Component:Add-ons", we typically point authors to the bugs if they don't have a Bugzilla user id - this still leaves a lot of open bugs in that component. Ideally, we get those moved off. As far as I remember, this component was created in order to help the Firefox devs deal with mem leak issues triggered by add-ons and as a way to track problems being faced by a significant portion of the user base. (I don't think it's worked well so far). My suggestion is to "migrate" all the open bugs to other systems and then archive that component.

Comment 15

•

17 years ago

The Add-ons component was mainly for bugs with specific extensions concerning AMO itself, like "my add-on isn't showing up" or "this extension stole my images".

Comment 16

•

17 years ago

(In reply to comment #15) > The Add-ons component was mainly for bugs with specific extensions concerning > AMO itself, like "my add-on isn't showing up" or "this extension stole my > images". Ah, yeah that's really not how it has been used then. In fact, all these issues went into "Administration". I agree with Basil that it would probably not hurt to empty out the Addons component and retire it in favor of the single Administration component.

Updated

•

17 years ago

Blocks: 460378

Comment 17

•

17 years ago

Filed bug 460378 about removing the misleading "Addons" component in bugzilla, WONTFIXing this per comment 12 etc.

No longer blocks: 460378

Status: REOPENED → RESOLVED

Closed: 17 years ago → 17 years ago

Resolution: --- → WONTFIX

Jorge Villalobos [:jorgev] (he/him)

Reporter

Comment 18

•

14 years ago

With the current frequent, rapid-release process in place for Mozilla applications, too many add-ons are becoming incompatible with current applications. These incompatibilities involve more than merely the maximum version number allowed for the affected application (contained in an add-on's install.rdf file). Real problems exist for some add-ons, especially for themes. Currently there is no effective, consistent way to report problems with individual add-ons hosted by addons.mozilla.org. Very few add-on pages in addons.mozilla.org have communication links to their developers. Others have links to Google queries without any clue as to which query result is the appropriate one for communicating with a developer. Many add-on pages provide no method at all for communicating with the developer. Furthermore, users cannot access reports by other users of add-on problems. This results in redundant attempts (often unsuccessful) to report problems to add-on developers. It also results in frustration for end-users who remain unaware that problems they are experiencing are actually known by others and are really in the add-ons and not in the user's own setup. If this cannot be implemented, then addons.mozilla.org needs to impose a policy that NO add-on can be hosted without a clear method of communicating with its developer being contained on the add-on's main Web page page and that, if the developer or the method of communicating changes, the page must be updated to reflect that change. A failure to keep contact information current should then result in the add-on being blocked from downloading with a note on the add-on's main addons.mozilla.org Web page explaining why.

Status: RESOLVED → REOPENED

Resolution: WONTFIX → ---

Comment 19

•

14 years ago

There's a Firefox > Extension Compatibility component on Bugzilla that can be used and is being used to report problems like these. AMO is still not a project hosting site, so I don't think it makes sense to create Bugzilla instance for add-ons, specially considering that most bugs reported there would go unnoticed by add-on developers. Finally, while I don't feel strongly either way about forcing developers to include contact information, doing so will only lead to /dev/null addresses that will only confuse and anger users. I prefer developers to not include any contact information if they don't intend to help their users, and I don't see why they should be forced to do so. When a compatibility problem is big enough (like widespread crashing), we can consider removing the listing and blocklisting. I think those measures are sufficient to deal with such problems where the developer is unresponsive to serious problems.

Jorge Villalobos [:jorgev] (he/him)

Comment 20

•

14 years ago

Also, I forgot to mention that all add-on listings on AMO now have a Report Abuse link on them, where users can communicate with us about specific problems. I review all of them (mostly junk) and every now and then need to poke a developer about a problem.