Bugzilla Fixup: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
No edit summary
No edit summary
Line 8: Line 8:
** Security fixes
** Security fixes
***  https://bugzilla.mozilla.org/show_bug.cgi?id=38862
***  https://bugzilla.mozilla.org/show_bug.cgi?id=38862
*** https://bugzilla.mozilla.org/show_bug.cgi?id=299401
** Create way to obsolete or hide past milestones
** Create way to obsolete or hide past milestones
** Add reports for (usually for past 7 and 14 days)
** Add reports for (usually for past 7 and 14 days)

Revision as of 05:23, 6 December 2007

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.
    • Add Microsummary feed type (similar to rss)
    • Security fixes
    • Create way to obsolete or hide past milestones
    • Add reports for (usually for past 7 and 14 days)
      • What people are working on (i.e. activity)
      • What a person has attached/landed
      • What has been checked in
      • What has a blocking flag, but not resolved
      • Whats been fixed in the last week
      • Whats been fixed between releases
    • Way to tell if a patch has been landed, and if so, where?
    • ajax front end type stuff to speed up front end and lower server load
      • i.e. re-sorts on client side should be done via JS
    • Solidify the XML API so a new UI can be build (kinda a P2, but needs to get started for long term progress)
    • 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
    • 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: https://bugzilla.mozilla.org/show_bug.cgi?id=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: https://bugzilla.mozilla.org/show_bug.cgi?id=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. (+1)
    • callek: Per Product/Component "watches" rather than a user needing to know a default QA/Assignee for the product/component.
      • callek: Ability for bug "moves" to generate mail when entering+leaving said product/component.