BugzillaImprovements

This is the collected input about changes community members would like to make to bugzilla.mozilla.org (June 2009).

Code

UI

Simpler Layout

Collapse all the non-required and less-frequently used fields by default. This would simplify the layout of bug reports and make it less daunting for new participants. Allow user prefs to control what gets expanded and collapsed by default for each user. More familiar, easier for new users, streamline navigation. -- chofmann

• bug 373418
• Note that we are unlikely to add a user preference for this, but we might remember the shown/hidden state in a cookie. -mkanat

No default UI changes

I [am not suggesting we require] any changes to the bugzilla UI. Firefox's needs are clearly sufficiently different from the rest of the world's that accommodating them is painful and invasive. I just want the tools to build a UI and workflow that suits us. -- shaver

• This would have to be specified more exactly. -mkanat

Text Area Visible On Filing

When I'm filing a bug, the text area in which I am to describe the bug should be above the fold. Everything else (including the component it's in) is subsidiary to the bug description itself, and should be farther down (or invisible -- why do I care who the default CC: is? why would I ever change the QA contact?) -- shaver

• Essentially fixed in Bugzilla 3.4, because the bug entry page is simpler by default.

Fix Mid-Air Collisions

Fixed mid-air collision handling, such that:

• there are no more false positives (mid-airs that don't actually over-write)
• changes to unrelated fields do not conflict
• changes to related fields are resolved "humanely" (if I added a dependency, and someone else removed another, those are not hard to reconcile)

-- shaver

• Bug 107306 - Smart midair collision handling with line-item overrides.
• Bug 69447 - Make CC changes not cause midairs.
• Bug 395970 - mid-air collision pages cry wolf.

• Note that this is somewhat difficult and unlikely to happen in any near-term Bugzilla release. -mkanat

Historical Queries

Ability to do historical queries on bug attributes ("what were all the bugs with blocking-firefox3.5+ on Friday?") so that people can stop scraping daily queries or trying to figure out the charting system.

• There is a WONTFIXed bug, but I can't find it right now.
• I think it would be better to just have charting system that can be understood and used by mere mortals. Also a charting system that can go back in time (perhaps a product separate from Bugzilla itself--some already exist). -mkanat

Flexible Fields

No mandatory fields; all fields should be able to be multi-valued (this would let us solve the resolved-vs-fixed-keyword problem, as well as "vista and win7 but not win XP", and would let us have bugs in multiple components, multiple assignees for bugs, etc. -- we can argue about whether we want to permit that in different parts of our product as a matter of policy, but the mechanism should be there) -- shaver

• bug 55970 would sort of accomplish this.
• This is already possible to some degree in Bugzilla 3.4 just by adding your own custom fields that appear per-product and that have per-product value lists. It will be even more possible in future versions of Bugzilla. -mkanat

Multiple Statuses/Resolutions (Per Branch)

I guess that finding out a better way to have "fixed here, but needs fixing somewhere else" would be cool, and support for that in queries. -- axel (endorsed by bsmedberg)

• Bug 55970 - Bugzilla needs to deal better with branches.

(I get the impression the requirements for this are complex! -- gerv)

Deprecation

Ability to orphan components/bugs/flags/etc. without a ton of noise. I should be able to make "fixed1.4.1" never show up in the keyword autocomplete without having to do a pile of bug-munging. -- shaver

• Bug 456743 - Add the ability to disable field values (mark them as inactive). Being worked on by ghendricks. (Note however that this doesn't affect bugs, flags, or keywords.)

JavaScript Autocomplete

I would like to see someone finish (or rewrite) the patch I attached to - JavaScript autocomplete for review request field. For bonus points, the same backend code should be used anywhere else that you currently enter someone's bugmail in the UI. I waste an awful lot of time guessing at people's bugmail. -- ted (and requested by johnjbarton for CC; endorsed by Ron K)

• bug 490923

Nicer Graphs

Nicer graphs would be good. -- dtownsend

Bug: too many to list. ;-)

Remove Severity Field

The "blocker" and "enhancement" severities actually mean something to us currently, but everything inbetween is basically "a bug of some sort" without much actionable difference. I think we should instead have a "blocking trunk" flag which we use to mark bugs which should close the mozilla-central tree, and an enhancement keyword to mark enhancement bugs. -- bsmedberg.

The Bugzilla project definitely uses this field -- mkanat.

Remove Platform/Hardware and OS

Remove platform and OS, use keywords for them instead (until the multi-value thing is resolved above) -- shaver (endorsed by bsmedberg)

According to the Bugzilla Survey (which will be published in the next few days, once I finish compiling all the data and writing it up), the single *most* common problem is that the op_sys or platform fields aren't applicable to what the users are doing with Bugzilla. -- mkanat.

• Bug 449161 - op_sys and platform should be custom fields with an extension for auto-selecting.
• Bug 160572 - You should be able to turn off URL, Platform, OS, Version fields in Bugzilla.

Another option is to remove them from the bug filing process, and have them default to All/All (or, better, new values: Unspecified/Unspecified - idea from Rich Gray).

Make More Field Visibilities Configurable Per Product

Would it be crazy to propose being able to vary the presence and default state of all the fields on a per-product basis? -- zw.

No, it wouldn't, but it would require a fair bit of re-working that we're in-progress on, in terms of architecture, in Bugzilla. -mkanat

Integrate Comments Into Bug History

If I'm reading a bug report for the first time, and trying to familiarize myself with what has happened on the bug so far, it's hard to know what actions in the bug comments correspond with what action in the bug history (renaming, changing component, change of status, etc.). If you could incorporate bug history and bug comments[1], it would make it much easier to put the bug history and comments into context. -- Chris Ilias.

• Bug 11368 - Move all bug activity onto main bug screen.

Keyword Subscriptions

The ability to subscribe to keywords. -- Chris Ilias

• Bug 278455 - Ability to "watch" based on any field.

"Next Action"

I want "next action" and "next action assignee" fields (replacing several existing fields). Then each contributor will be able to find bugs they can help with, and fewer bugs will fall into the trap of being part of an unmanageable "pile of stuff".

Bernd, Chris Lawson, alanjstr, Frederic Wenzel, and Brendan Eich are all enthusiastically in support of this proposal.

http://www.squarefree.com/2009/04/20/getting-bugs-done/

http://groups.google.com/group/mozilla.dev.planning/browse_thread/thread/aa627caed996d9bc

Accounts

Hide from Autocomplete

Relatedly, people should be able to hide their accounts from auto-completion or partial matching. -- shaver

• Bug: none.

Server

API

A full REST+JSON API, so that anything currently possible through the bugzilla web UI (read or write) can be done through another program on another server. -- shaver

Including chart data. -- dtownsend

• A JSON API already exists; need to assess completeness and level of documentation. "Bugzilla 3.6 will have a JSON-RPC API that duplicates the XML-RPC API." -- mkanat.

Note that in order for this to be REST, Bugzilla has to move to Catalyst, a far-reaching rearchitecture that is in the Bugzilla 4.0 or 4.0+ timeframe. JSON-RPC will exist in Bugzilla 3.6, though.

Access-Control-Allow-Origin header support for cross-site XML-RPC - asutherland.

Server-Side Hooks

Server-side hooks for basically every action, so that f.e. I could write something that did component watching the way I want without having to even discuss it with upstream, let alone make it sufficiently general to be accepted. -- shaver

• These already exist: http://www.bugzilla.org/docs/tip/en/html/api/Bugzilla/Hook.html -- more can be added as requested; hooks are only added that have use cases. Some rearchitecture is required before we can add hooks to performance-critical areas. (Can't find the bug, right now.) -mkanat

Shorter Query URLs

Shorter query URLs by default. -- axel

• Already implemented in Bugzilla 3.4.

Bounce Tracking

Bug 209181 will save lots of time when processing a lot of bugs and you need to know if reporter mail has not bounced. -- Nikolay Shopik

• Bug 209181 - Bounce on bug reporter email should be noted.
• Note that due to the code complexity and setup complexity vs. functional gain, we are unlikely to implement this in the near future. -mkanat

Charts

• Make it possible to extract chart data without a login. -- dtownsend.
• Support for GROUP BY equivalent. -- dveditz (endorsed by axel).
  • I think what Axel wanted was just a way of getting the tabular data in a programmatic format, which we can already do (CSV). -mkanat

Search

Improved search, both in criteria and in result output. [Make it so people don't use gmail search in preference to Bugzilla search.] -- shaver.

• We already have ideas for improving the search UI that have been approved all around. In terms of functionality, we'd need more specific problems that need fixing, for us to address. -mkanat

Google-type atributes: search on 'xyz' +<someword> etc. -- NoOp.

Hierarchical Components

Let me pick "Page Behaviour" if I know it's a content-side problem, and then we can narrow to layout/DOM/script (or multiple, if it's a script<->DOM interaction!) later. I can "watch" Page Behaviour, or query on it, but the JS team can do that for script stuff more narrowly if they only care about that. -- shaver.

Proper Component Watching

Following fake QA Contacts is hacky, and breaks when people don't reset the field when moving bugs. -- dolske.

bug 278455

Bugmail

Steffen Wilberg says:

• Bug 97956 - Give summary and URL of bugs added or removed from dependencies in bugmail (notification mail).

• Bug 125888 - Give summary/URL of bugs marked as duplicates.

Resolution Timestamp As Field

It would be nice to add the resolution timestamp to the front of the bug, near the opened and modified times (blank if the bug is not resolved or reopened, and the most recent resolution if the bug was reopened and then re-resolved). Would also be nice to have that available as a column in buglists. -- dveditz.

This would probably require it to be stored as a DB field, set/unset when the bug changes state. -- gerv

Speed

Lots of people requested that Bugzilla be made faster, and suggested a number of ways that this could be achieved. However, we should test before optimizing. Some possibilities, though:

• Template Toolkit buffers all output, although in the past b.m.o. has had flushing hacks -- bbaetz.
• MySQL doesn't support cursors, so any select result has to entirely be pulled out of the DB, so it wouldn't be possible to display the output of buglists as it comes anyway. -- bbaetz.
  • Not true--I'm pretty sure MySQL 5 supports cursors. -mkanat
• Reduce page weight for show_bug.
  • I doubt this is a serious (top 10) performance issue for anybody not on dial-up. -mkanat

Parallelization

Support for parallelizing queries across multiple servers, since mining this data will become increasingly resource-intensive. -- shaver

• I think that a single server can handle any single query in Bugzilla, and if it can't, then we just need to optimize the search code. Yahoo has already done some optimizations for their Bugzilla, but we have to wait for them to be authorized to open-source them. -mkanat

Caching

Intelligent caching of API and web-UI results, based on modification time for bugs; "generate on change" via the server side hooks would be a DIY option, certainly. You can cache different versions based on relevant groups; Vary is analogous in HTTP, and this isn't a research problem in the web-application space. The vast majority of bugs have no group issues at all. Speed and other resource usage is very much the concern -- sending a 301 back instead of generating a pile of HTML is a win for everyone, especially as API use becomes more common. -- shaver. Endorsed by axel.

bug 167808

Configuration

Reduce Product and Component Count

At least 80% fewer components, and many fewer products. We have 8 different DOM components, but nowhere obvious to put postMessage; 7 Java-related components; 12 different layout components; SQL (not supported anywhere, and not related to our own sqlite use or APIs); 9 different widget components, etc. -- and that's just Core. Mostly these subdivisons seem to be used as ways to narrow queries or get bugmail people want, all of which I think would be done better through attribute-based notifications/queries instead of something between the reporter and the bug. (I routinely have to take an entire minute just to figure out what product+component I want to file a bug, and I usually already know what code it's in!) The problems are bug filing complexity, query complexity, choice paralysis, how quickly it gets out of date, the costs the bugzilla imposes for _removing_ components, the grotesque effects on the UI. I _know_ things about the kind of bug it is, just let me specify it in a way that doesn't make me read all the descriptions of the components. -- shaver

Bugs

• Can't put an alias in a bookmarkable template.