Bugzilla Fixup

From MozillaWiki
Jump to: navigation, search

We have kicked off a project to improve Bugzilla, specifically to help the Mozilla team be more efficient and effective when using the tool. In this first stage, we are looking to address low-hanging fruit that can addressed quickly with minimal change. In later phases we'll address some of the longer term issues.

Please add suggestions under "Suggestions/nominations" along with your name/email. We'll evaluate the the suggestions and fit it in ASAP based on all feedback and difficulty.

  • Stage 1
    • Send mail asynchronously - don't block the results page while mail is sending when editing a bug. (bug 284184)
    • Add Microsummary feed type (similar to rss) (bug 339007)
    • Security fixes
    • Create way to obsolete or hide past milestones (bug 77193)
    • Add reports for (usually for past 7 and 14 days)
      • What people are working on (i.e. if a person has made any change to a bug)
      • What a person has attached/landed (relies on other functionality)
      • What has been checked in (relies on other functionality)
      • What has a blocking flag, but not resolved
      • What's been fixed in the last week (closed "fixed")
      • What's been fixed between releases (closed "fixed")
    • Re-sorts on client side should be done via JS
    • Fix search clobbering. If you have two searches in two windows (same instance), the first search will fall out of scope and links won't work.
  • Stage 2
    • Backport https://bugzilla.mozilla.org/buglist.cgi?bug_id=174085,329701,405476 from 3.2
    • https://bugzilla.mozilla.org/show_bug.cgi?id=251556 (regression flags)
    • https://bugzilla.mozilla.org/show_bug.cgi?id=38862
    • Way to tell if a patch has been landed, and if so, where?
    • user profile checkboxes to control whether or not each user is currently accepting review requests of each type; ONLY those users are accepted as review request targets. No more blank/blackholed review requests. Use only those users for autocompletion of partial names, of course. (roc)
    • Add a column in search results containing patches with current review flags or display more obviously an attachment is a patch. Also, display the status of a patch (review?/+/-, etc)
    • Multi-state flag (nominate, blocks release, blocks final, arbitrary), deprecate options, one flag per branch
    • Back-port 3.2 addition of flags and groups to quicksearch
  • Stage 3
    • Solidify the XML API so a new UI can be build (kinda a P2, but needs to get started for long term progress)
    • better bug reporting forum (more wizard like)
    • In bugmail, include a quick header which includes (customizable): flags, any patch status, priority, component, and bug assignee.
    • Add a "view source" link to attachments (bug 346255)
    • New UI for bugzilla using the API
    • Create user pref for user keybindings
    • Reports - can't edit reports, have to share on create, one shot to create report - can't edit, can't delete - just improve this
    • Replace the barely functional branch-tracking flags (bug 336790)

Suggestions/nominations

  • roc: user profile checkboxes to control whether or not each user is currently accepting review requests of each type; ONLY those users are accepted as review request targets. No more blank/blackholed review requests. Use only those users for autocompletion of partial names, of course. (+4)
  • callek: Per Product/Component "watches" rather than a user needing to know a default QA/Assignee for the product/component. (+2)
    • callek: Ability for bug "moves" to generate mail when entering+leaving said product/component.
  • dbaron: user nicknames (user-chosen, system-unique) that, when entered exactly, take priority over autocomplete in cc: and review requests (+2)
  • reed: I have a list of bugs I've wanted in bmo for a while tagged with the "[wanted-bmo]" tag in the status whiteboard. Check out the list here.
  • faaborg: export search results to JSON and provide a front end to the search results based on MIT's Exhibit so users can do faceted browsing on the data. Here is an example of the Firefox 3 PRD in exhibit (+1)
  • gavin: bug 251556 - proper regression tracking, distinct from "blocked/depends on" tracking. I've been wanting this forever, and I think the cost/benefit ratio for fixing it is very low. (+3)
  • shaver: REST (contra: XML-RPC) APIs for search and bug manipulation (but especially search!) (+1)
  • cbarrett: Ability to receive different bugmail for watches. i.e. I want to get email when a new bug is filed in widget:cocoa, and I want to see when smichaud, josh, or shebs attach patches, but not any of their other activity.
  • cbarrett: The format of bugmail messages requires that you 1) use a fixed-width font and 2) hard wrap at 80 characters. Lift both of these restrictions.
    • These are not "restrictions", they are intentional. There are long discussions in bugs about why they are both a good idea. (Just so you know.)
  • gerv: what does "New UI for bugzilla using the API" mean? A XUL client? Ajax?
  • dolske: Integrate with Build:TryServer, to allow submitting a patch directly from Bugzilla
  • dolske: Integration with CVS/Hg and LDAP, so that users with checkin powers can do directly from Bugzilla (w/ checkin messages autogenerated). Future work could add warnings (or errors) if you're trying to checkin something without appropriate review and approval. And, vice versa, if something is checked into a repository without a corresponding bug. (-1)
  • bsmedberg: Remove most bug fields (severity/priority/target milestone/Hardware/OS/keywords/flags) with googlecode-style tags. Tags should be group-controllable like flags are currently. See Joel on Software for why our fields hurt more than they help. (+2) (-1)
  • dolske: make interdiffs actually work. Often they just completely fail with "Warning: this difference between two patches may show things in the wrong places due to a limitation in Bugzilla when comparing patches with different sets of files. "
  • dolske: Improve searching. A common user complaint is that the main search box on the front page is worthless. The tiny quicksearch box in the header is better, but could also be improved.
  • mrbkap: Make something like bug 301656 an option.
  • hwaara: I concur with dolske above; improve searching! I think searching right now is mostly useless; I can never find what I want, unless I know a very specific substring of the bug title, or its bug id.
  • gavin: support for git-style diffs - since we're going to be moving to Hg (and in fact many people already have), more and more git-style diffs are going to be used on bmo. it would be nice if the patch viewer supported them with all the features (context adjustment, links to the actual files in LXR, etc.)
  • reed: canned responses (+1)
  • RyanVM: I wish I could optionally have an entire bug emailed to me when I CC myself to it to have the entire history in my mailbox instead of only the history after CCing.
  • dmose: facet-based searching, a la the Thunderbird seek extension
  • jcranmer: Ability to see the changes over time of complex queries without having to create datasets. Example: average age of closed bugs.
  • justdave: Ability for the reporter to remove a bug from a security group, as promised by Mozilla's security policy. (bug 128590)
Retrieved from "https://wiki.mozilla.org/index.php?title=Bugzilla_Fixup&oldid=293270"