Bugzilla Fixup

From MozillaWiki
Revision as of 09:24, 13 February 2008 by Hwaara (talk | contribs)
Jump to navigation Jump to 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
    • Way to tell if a patch has been landed, and if so, where?
    • Solidify the XML API so a new UI can be build (kinda a P2, but needs to get started for long term progress)
    • 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)
    • Reports - can't edit reports, have to share on create, one shot to create report - can't edit, can't delete - just improve this
    • Multi-state flag (nominate, blocks release, blocks final, arbitrary), deprecate options, one flag per branch
    • Replace the barely functional branch-tracking flags (bug 336790)
    • Back-port 3.2 addition of flags and groups to quicksearch
  • Stage 3
    • 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

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. (+3)
  • callek: Per Product/Component "watches" rather than a user needing to know a default QA/Assignee for the product/component. (+1)
    • 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 (+1)
  • 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. (+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.