BugzillaImprovements

From MozillaWiki
Jump to: navigation, search

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

There are a number of older suggestions here.

Code

UI

Simpler Bug 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

Another option would be to have some of the key fields, plus the Commit button, as position:fixed at the top of the Window. This means that the general status of the bug is always visible, even if you visited a #comment-id link. And your muscle memory always knows where Commit is, as well. -- gerv

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. -- mkanat
    • Not if your screen is 1024x768 -- gerv.
      • I see part of the Description field above the fold at that resolution, even including an extra toolbar from a plugin in my browser. That's enough that it can be clicked on. -mkanat

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
    • mkanat: can you point me at any technical analysis which has been done on the problem? -- gerv
      • No, but I have a general idea of how it would be implemented, in my mind, if you want to talk about it. I think we should probably be looking at having a Bugzilla::ChangeSet object first (which we need for other things, also) -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
  • the ability to share charts would help. Right now the datasets for the "new" charts are either set up by an admin, or personal and not shareable. Even though the data sets are not shareable they still bloat the drop-down. Charts don't help with historical data, unless you thought to set up the charts before you wanted the answer -- useless. But maybe if someone else has already asked the question you have a chance of using their data. I (dveditz) would like two changes:
    • Let me share my data sets the way I can share my named queries.
    • When I'm making a chart I only want to choose from the datasets you'll give me the data for, don't confuse me with the rest and then fail silently when I choose them.

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)

  • There is an existing custom feature on b.m.o., but it is considered inadequate. (any solution that results in 118 "fixed" keywords and an equal number "verified" keywords is horrible, not to mention the stack of "blocking" flags cluttering up each bug.)
  • Bug 55970 - Bugzilla needs to deal better with branches.
  • Despite the WONTFIX I still prefer the simpler Bug 336790 --dveditz
    • Of course, as extensively explained in that bug, while that might serve Mozilla's requirements, it would not serve the general requirements of all Bugzilla installations, and it also would not be very flexible once you wanted more and more things per-branch, or if you wanted to say things like "this is the same bug in two different products". -mkanat

(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, Peter Weilbacher)

Autocomplete actually isn't even that hard. We just have to find a good XML-RPC or JSON-RPC client in JavaScript that we can include in Bugzilla that has a license compatible with the MPL, so that it can get the data it requires. -- mkanat

Nicer Graphs

Nicer graphs would be good. -- dtownsend

Bug: too many to list. ;-)

Repeating my (dveditz) earlier comment in the "historical data" section, the "new" charts need

  • the ability to make datasets public or shared with specific groups (like named queries). I mean user-created datasets, there do seem to be a few public ones I assume created by admins.
  • don't show 100's of datasets that the user isn't allowed to use. The clutter hides the ones I'm looking for, the interesting-looking names are a tease, and it's just overall frustrating. Just show me my own datasets, the public ones, and the ones that have been shared with me.

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.
  • We should still split "enhancement" from "defects" rather than lumping them in the same severity field. In particular the current scheme means we cannot assign "severity" (importance?) to an enhancement, which can range from a minor polish thing to major new functionality. --dveditz

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

The presence of a field could be easily customized in each site's local CSS if we had a few tweaks to the bug layout:

  • each item must have an id. A lot of 'em do, but some the field itself has an id but its label does not, making it hard to style them as a group (e.g. target milestone and many others).
  • The body should have a product class in addition to the existing component class, that is "bz_product_Core" alongside "bz_component_JavaScript_Engine"
    (dveditz)

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. (zomg +1 -- beltzner) (+1 -- dveditz, can't tell you the amount of time I spend on the history page trying to match state changes to explanatory comments)

  • 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, dmose and Brendan Eich are all enthusiastically in support of this proposal.

Next Action could be trialled using custom fields, but not Next Action Assignee. -- mkanat

Integration

There have been several calls for greater linkage between Bugzilla and Hg, although there are different views about the appropriate extent of the scope, and the UI, for such linkage. The problem they are attempting to solve is easily finding the appropriate checkins for the bug.

Editable Description/Summarization

Sometimes it takes a while to hone in on what a bug really is, with several of the initial comments being overbroad or over-vague. Sometimes a bug is "mostly" fixed but left open, but you have to find comment 87 to figure out what the bug is still open for. It would be nice if a bug could be resummarized, and if it is the new summary would appear above the initial comment 0. Creating and editing this field would be restricted to the editbugs group, and if one is added it might have to be somewhat visually set off from the stream of comments starting with #c0. --dveditz

A specific Bugzilla feature for this appears to be WONTFIX because supposedly there's enough support for this as a customization. bug 99240:

Since Bugzilla 3.1.2, you can create a custom textarea and then paste the bug description in it. We won't implement a specific "long summary" field as you are free to create one yourself when you need it.

I'm not sure who the "you" is there, it certainly doesn't seem to be me. The same concept was also requested in bug 262087

Accounts

Hide from Autocomplete

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

  • Bug: none.

Login Name != Email Address

would really help me, as it would probably also change what is displayed as the "who" of flags settings. We currently have a good number of people who are using a bugzilla@foo.tld Bugzilla account, and it's very unhelpful to see "bugzilla: review+" on an attachment.

A faster, more lightweight solution to that may be to have a tooltip with the full name/mail appearing when mousing over such a shortened name (usually with flag settings).

  • Bug 218917 - Allow login_name != email_address, so address isn't displayed (anti-spam effect too).

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. -- mkanat

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

  • for public (no cookies) data only, I hope --dveditz

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
      • Yes, this is neat. Looked at reports and didn't understand the UI before, but now I get it. Including this into a JSON API would be nice for consistency. -Axel
      • Yeah, that's what I wanted. Could do with support for grouping by flag/requests/requestee (and "fixed-in" if ever BMO gets to use that) but otherwise covers what I was thinking of.

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.
    • This already exists in both quicksearch and "find a specific bug". (At least, the + and - operators exist.) -mkanat

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). Endorsed by Rich Gray.
  • 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

Default-Uncheck Flag Assignment Acceptance

  • b.m.o. has a local customization allowing people to define whether they are accepting flag assignments (e.g. review requests) for each flag. These should be default-unchecked rather than default-checked. Perhaps we could also have a flag day (groan) where we uncheck everyone's flags, then check them again for all people who have plussed a flag of that type in the past. This would be a good first guess at the set of people who actually accept such requests.
    • This wouldn't work, because sometimes I want to request review from somebody who's not a reviewer--say, somebody who can tell me whether or not their problem is fixed, or some expert in some area that I'm working on, and if their flags defaulted to off, then I couldn't ask them. -mkanat
  • Later, this acceptance data should be tied into the autocomplete system.

Bugs

  • Can't put an alias in a bookmarkable template.
  • Add Core to the pretty picker bug 384603

Already Implemented

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

Shorter Query URLs

Shorter query URLs by default. -- axel

  • Already implemented in Bugzilla 3.4.
    • meanwhile BMO users can use a bookmarklet (admittedly an inconvenient extra step)
Retrieved from "https://wiki.mozilla.org/index.php?title=BugzillaImprovements&oldid=168365"