Account confirmers, Anti-spam team, Confirmed users, Bureaucrats and Sysops emeriti
4,925
edits
BugzillaImprovements: Difference between revisions
no edit summary
(→Server) |
No edit summary |
||
| Line 45: | Line 45: | ||
Bug: none. | Bug: none. | ||
=== Multiple Statuses/Resolutions === | === 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 | 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 | * [https://bugzilla.mozilla.org/show_bug.cgi?id=bz-branch Bug 55970] - Bugzilla needs to deal better with branches. | ||
(I get the impression the requirements for this are complex! -- gerv) | |||
=== Deprecation === | === Deprecation === | ||
| Line 59: | Line 61: | ||
=== JavaScript Autocomplete === | === 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 | 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) | ||
* [https://bugzilla.mozilla.org/show_bug.cgi?id=386600 Bug 386600] - JavaScript autocomplete for review request field (patch, July 2007) | * [https://bugzilla.mozilla.org/show_bug.cgi?id=386600 Bug 386600] - JavaScript autocomplete for review request field (patch, July 2007) | ||
| Line 68: | Line 70: | ||
Bug: too many to list. ;-) | 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. | |||
* [https://bugzilla.mozilla.org/show_bug.cgi?id=449161 Bug 449161] - op_sys and platform should be custom fields with an extension for auto-selecting. | |||
* [https://bugzilla.mozilla.org/show_bug.cgi?id=160572 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. | |||
| Line 87: | Line 113: | ||
Including chart data. -- dtownsend | Including chart data. -- dtownsend | ||
* A JSON API already exists; need to assess completeness and level of documentation. | * 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. | ||
Access-Control-Allow-Origin header support for cross-site XML-RPC - asutherland. | |||
=== Server-Side Hooks === | === Server-Side Hooks === | ||
| Line 108: | Line 136: | ||
* Make it possible to extract chart data without a login. -- dtownsend. | * Make it possible to extract chart data without a login. -- dtownsend. | ||
* Support for GROUP BY equivalent. -- dveditz (endorsed by axel). | |||
== Speed == | == Speed == | ||
| Line 126: | Line 155: | ||
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!) -- shaver | 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!) -- shaver | ||
= Bugs = | |||
* Can't put an alias in a bookmarkable template. | |||