canmove, Confirmed users
345
edits
BugzillaImprovements: Difference between revisions
Jump to navigation
Jump to search
Adding links to bugs and my responses to items.
No edit summary |
(Adding links to bugs and my responses to items.) |
||
| Line 9: | Line 9: | ||
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 | 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 | |||
=== No default UI changes === | === No default UI changes === | ||
I [am not suggesting we require] any changes to the bugzilla UI. Firefox's needs are clearly sufficiently different from the rest of the world's that accommodating them is painful and invasive. I just want the tools to build a UI and workflow that suits us. -- shaver | I [am not suggesting we require] any changes to the bugzilla UI. Firefox's needs are clearly sufficiently different from the rest of the world's that accommodating them is painful and invasive. I just want the tools to build a UI and workflow that suits us. -- shaver | ||
* This would have to be specified more exactly. -mkanat | |||
=== Text Area Visible On Filing === | === Text Area Visible On Filing === | ||
| Line 19: | Line 22: | ||
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 | 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. | ||
=== Fix Mid-Air Collisions === | === Fix Mid-Air Collisions === | ||
| Line 32: | Line 35: | ||
* [https://bugzilla.mozilla.org/show_bug.cgi?id=69447 Bug 69447] - Make CC changes not cause midairs. | * [https://bugzilla.mozilla.org/show_bug.cgi?id=69447 Bug 69447] - Make CC changes not cause midairs. | ||
* [https://bugzilla.mozilla.org/show_bug.cgi?id=395970 Bug 395970] - mid-air collision pages cry wolf. | * [https://bugzilla.mozilla.org/show_bug.cgi?id=395970 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 | |||
=== Historical Queries === | === Historical Queries === | ||
| Line 38: | Line 43: | ||
* There is a WONTFIXed bug, but I can't find it right now. | * 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 | |||
=== Flexible Fields === | === Flexible Fields === | ||
| Line 43: | Line 49: | ||
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 | 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) === | === Multiple Statuses/Resolutions (Per Branch) === | ||
| Line 57: | Line 64: | ||
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 | 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 | ||
* [https://bugzilla.mozilla.org/show_bug.cgi?id=456743 Bug 456743] - Add the ability to disable field values (mark them as inactive). Being worked on by ghendricks. | * [https://bugzilla.mozilla.org/show_bug.cgi?id=456743 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 === | === JavaScript Autocomplete === | ||
| Line 63: | Line 70: | ||
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) | 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) | ||
* | * {{bug|490923}} | ||
=== Nicer Graphs === | === Nicer Graphs === | ||
| Line 94: | Line 101: | ||
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. | 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 | |||
===Integrate Comments Into Bug History=== | ===Integrate Comments Into Bug History=== | ||
| Line 140: | Line 149: | ||
* 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. | * 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. | |||
Access-Control-Allow-Origin header support for cross-site XML-RPC - asutherland. | Access-Control-Allow-Origin header support for cross-site XML-RPC - asutherland. | ||
| Line 146: | Line 157: | ||
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 | 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 | ||
* These already exist: http://www.bugzilla.org/docs/tip/en/html/api/Bugzilla/Hook.html -- more can be added as requested; hooks are only added that have use cases. Some rearchitecture is required before we can add hooks to performance-critical areas. (Can't find the bug, right now.) -mkanat | |||
=== Shorter Query URLs === | === Shorter Query URLs === | ||
| Line 158: | Line 171: | ||
* [https://bugzilla.mozilla.org/show_bug.cgi?id=209181 Bug 209181] - Bounce on bug reporter email should be noted. | * [https://bugzilla.mozilla.org/show_bug.cgi?id=209181 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=== | ===Charts=== | ||
| Line 163: | Line 177: | ||
* 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). | * 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 | |||
===Search=== | ===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. | 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 | |||
===Hierarchical Components=== | ===Hierarchical Components=== | ||
| Line 175: | Line 192: | ||
Following fake QA Contacts is hacky, and breaks when people don't reset the field when moving bugs. -- dolske. | Following fake QA Contacts is hacky, and breaks when people don't reset the field when moving bugs. -- dolske. | ||
{{bug|278455}} | |||
===Bugmail=== | ===Bugmail=== | ||
| Line 191: | Line 210: | ||
* Template Toolkit buffers all output, although in the past b.m.o. has had flushing hacks -- bbaetz. | * 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. | * 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. | * Reduce page weight for show_bug. | ||
** I doubt this is a serious (top 10) performance issue for anybody not on dial-up. -mkanat | |||
=== Parallelization === | === Parallelization === | ||
Support for parallelizing queries across multiple servers, since mining this data will become increasingly resource-intensive. -- shaver | 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 === | === Caching === | ||
| Line 202: | Line 225: | ||
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. | 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 = | = Configuration = | ||