From d819eae3af3b13d4b6f17e818d449eaabe58ff9d Mon Sep 17 00:00:00 2001 From: "barnboy%trilobyte.net" <> Date: Sat, 11 Aug 2001 05:13:47 +0000 Subject: Checkin for 2.14 release. Still some problems; this cannot yet be used for 2.14 documentation due to inconsistencies. --- docs/sgml/future.sgml | 328 +++----------------------------------------------- 1 file changed, 16 insertions(+), 312 deletions(-) (limited to 'docs/sgml/future.sgml') diff --git a/docs/sgml/future.sgml b/docs/sgml/future.sgml index 4cdf9e6f8..2e048dc5e 100644 --- a/docs/sgml/future.sgml +++ b/docs/sgml/future.sgml @@ -3,326 +3,30 @@ The Future of Bugzilla Bugzilla's Future. Much of this is the present, now. -
- Reducing Spam - -Those who use Bugzilla frequently are probably used to notification spam -- unwanted or unnecessary notifications. A number of proposals have -been put forward to attempt to reduce this. - -1. Reduce CC Spam - -Some of you probably know me as that guy who CCs on heaps and heaps of -bugs. Just as you get a lot of CC changes from me, so do I get a lot -from others. Why should CC changes send out email notifications? - -It's not necessarily the best idea to just remove the CC spam, there are -other issues too, like the difficulty of adding to large CC fields. - -For these reasons and more, an RFE for a per user "BCC" facility exists -that people could use to silently and privately track bugs, in a similar -way to voting today, but applying to an unlimited number of bugs. See -"http://bugzilla.mozilla.org/show_bug.cgi?id=7345". - -2. Bulk Changes - -You know the drill - a large milestone change, a component movement, -whatever, and lots of notifications are generated. If there's enough -maybe you'll just go delete, delete, delete, whoops, there goes another -notification that wasn't from the bulk change you missed. - -Shouldn't bulk changes send out one notification? A proposal for this -is at "http://bugzilla.mozilla.org/show_bug.cgi?id=26943". - -3. Configurable Notification Criteria - -It would be good if you could choose what you want to receive. There -are two parts to this. - -(a) Choose a selection of bugs you're interested in. This would be -similar to CC except you let the set be computed from selection criteria -rather than limited to the bugs your name is on. There is currently a -limited version of this in the bugzilla preferences, ie "all qualifying -bugs"/"all qualifying bugs except the ones I change"/"only those bugs -which I am listed on the cc line". -(b) Choose what changes will trigger a notification for the bugs you are -watching. With this, you could choose whether you want to receive cc, -dependency and keyword changes, for example. - -Both of these proposals live at -"http://bugzilla.mozilla.org/show_bug.cgi?id=14137". -Note that they also live at -"http://bugzilla.mozilla.org/show_bug.cgi?id=17464", and the change -has been checked in. This is fixed with Bugzilla 2.12 and is no longer -an issue. Woo-Hoo! - -
- -
- Better Searching - -Current searching tools in Bugzilla include the querying mechanism, -special summary reports and dependency trees. This message is about new -facilities. - -1. General Summary Reports - -For some time now it has been apparent to me that the query bug list -leaves a little to be desired in its linear nature. There is a need to -have categorised subsets, and counts of each category. If you don't -believe me, how about these facilities already in place or which people -have asked for: - -Most Doomed Reports - Categorised On Assignee, Shows and Counts Number -of Bugs For Each Assignee -Bug #15806 (Most Voted For Bugs) - Categorised On Product, Shows Bugs -Voters Most Want Fixed -Bug #9789 (BugAThon Tracking Page) - Categorised On Developer (Subset), -Counts Number of Bugs -Bug #9409 and #9411 - The desire to be able to report on more subsets. - -Hopefully you can see the gist of what is desired here. It's a general -reporting mechanism. - -This mechanism lets you choose the subset of bugs to operate on (like -query), let's you categorise them, possibly along with subcategories and -counts the number of bugs within each category. It might or might not -show the actual bugs themselves, and it might limit the number of bugs -within a category, or categories to report on. - -I'm further sure that many applications of this mechanism would only be -recognised once it was implemented. - -The general summary reports bug is at -"http://bugzilla.mozilla.org/show_bug.cgi?id=12282". - -2. Related Bugs - -It would be nice to have a field where you could enter other bugs -related to the current bug - it would be handy for navigation and -possibly even finding duplicates. See -"http://bugzilla.mozilla.org/show_bug.cgi?id=12286". - -3. Column Specification Support - -Currently query seems to get what columns to report on from whatever the -user last used. This doesn't work well for "prepackaged queries", where -you followed a link. You can probably add a column by specifying a sort -column, but this is difficult and suboptimal. - -Furthermore, I find that when I want to add a column to a query, it's -usually a one off and I would prefer it to go away for the next query. -Hence, it would be nice to specify the columns that appear on the query -(and general summary report) pages. The default query mechanism should -be able to let you specify your default columns. - -This proposal lives at -"http://bugzilla.mozilla.org/show_bug.cgi?id=12284". - -
- -
- Description Flags and Tracking Bugs - -Since I last posted on this issue, we now have "keywords" that solve -many of the issues of description and status whiteboard keywords. We -have seen a migration towards keywords, but there is still further to -go. - -Description ( + Status Whiteboard ) Keywords --------------------------------------------- - -Some description keywords remain. I'd like to hear what reasons, other -than time, there are for these staying as they are. I'm suspecting many -are not really being used. Hopefully we can totally remove these -eventually. - -Tracking Bugs -------------- - -When I suggested keywords, I did so to get rid of tracking bugs too, -though we've had less success on that front. - -There are many disadvantages to tracking bugs. - -- They can pollute bugs counts, and you must make sure you exclude -them. I believe the meta keyword might be used for this purpose. -- They have an assignee but there is nothing to fix, and that person can -get whined at by Bugzilla. -- It would be better to craft your own "dependency tree" rather than -rely on a fixed hierachy in the bug system. -- In creating a nice little hierachy, many bugs duplicate information -that should be available in other ways, eg -"http://bugzilla.mozilla.org/show_bug.cgi?id=12833" which is -about beta 1 networking issues. These could fall behind the actual -data. What tracking bugs are good for, ad hoc lists, is what keywords -are better for. -- An automatically generated dependency structure between one "tracking -bug" and another would be better than a manual one, since it gives exact -rather than manually set up classifications. - -Probably the only feature preventing tracking bugs being replaced is the -dependency tree. The quintessential tracking bug seems to be bug #7229 -"chofmann's watch list", which probably has about a couple of hundred -bugs at various levels, which allows a nice visualisation. - -Before keywords can replace tracking bugs better visualisation is going -to be required. General summary reports and dependency forests of a bug -list ("http://bugzilla.mozilla.org/show_bug.cgi?id=12992") could both -help, but neither solves the problem totally. Perhaps keywords within -keywords would help here. In any case, I'm still thinking about this -one. - -Some tracking bugs could definitely be turned into keywords immediately -though, and I'll point the finger at -"http://bugzilla.mozilla.org/show_bug.cgi?id=7954" here since that's -what came to mind first. - -
- -
- Bug Issues - -1. Inline Bug Changes - -Why do I see so many "moving to M5" and "reassigning to blahblah" -messages, and in other circumstances none are entered? Why aren't these -automatically generated? A comment should be only necessary when there -is something to add, and if I'm not interested in this sort of -information, I should be able to hide it. - -At the moment we're in a hybrid world where we don't get everything, but -we can't get rid of the bug change "messages" either. Furthermore, -"View Bug Activity" requires me to manually cross reference events on -another page, rather than being able to visually see the chronological -order. Shouldn't I be able to see all the information on one page? - -A proposal to allow bugs to be shown either way is at -"http://bugzilla.mozilla.org/show_bug.cgi?id=11368". - -2. Hard Wrapping Comments - -One thing that annoys me is the fact that comments are "hard wrapped" to -a certain column width. This is a mistake Internet Mail and News has -made, unlike every word processor in existence, and as a consequence, -Usenet suffers to this day from bad software. Why has Bugzilla repeated -the problem? - -Hard wrapping to a certain column width is open to abuse (see old -Mozilla browsers that didn't wrap properly, resulting in many ugly bug -reports we have to read to this day), and furthermore doesn't expand to -fill greater screen sizes. I'm also under the impression the current -hard wrap uses a non-standard HTML facility. See -"http://bugzilla.mozilla.org/show_bug.cgi?id=11901". - -3. REMIND and LATER Are Evil - -I really hate REMIND and LATER. Not because they mean something -won't be implemented, but because they aren't the best solutions. - -Why are they bad? Well, basically because they are not resolved, yet -they are marked as such. Hence queries have to be well crafted to -include them. - -LATER, according to Bugzilla, means it won't be done this release. -There is a better mechanism of doing this, that is assigning to -nobody@mozilla.org and making the milestone blank. It's more likely to -appear in a casual query, and it doesn't resolve the bug. - -REMIND, according to Bugzilla, means it might still be implemented this -release. Well, why not just move it to a later milestone then? You're -a lot less likely to forget it. If it's really needed, a keyword would -be better. - -Some people can't use blank milestones to mean an untargetted milestone, -since they use this to assess new bugs that have no target. Hence, it -would be nice to distinguish between bugs that have not yet been -considered, and those that really are not assigned to any milestone in -the future (assumedly beyond). - -All this is covered at -"http://bugzilla.mozilla.org/show_bug.cgi?id=13534". - -4. Create An Enhancement Field - -Currently enhancement is an option in severity. This means that -important enhancements (like for example, POP3 support) are not properly -distinguished as such, because they need a proper severity. This -dilutes the meaning of enhancement. - -If enhancement was separated, we could properly see what was an -enhancement. See "http://bugzilla.mozilla.org/show_bug.cgi?id=9412". I -see keywords like [RFE] and [FEATURE] that seem to be compensating for -this problem. - -
- -
- Database Integrity - -Bugzilla could be more proactive in detecting suboptimal situations and -prevent them or whine about them. - -1. Bugzilla Crime #1: Marking A Bug Fixed With Unresolved Dependencies - -It can't be marked fixed with unresolved dependencies. Either mark it -INVALID (tracking bugs), fix the dependencies at the same time, or -resolve the blockers. - -See "http://bugzilla.mozilla.org/show_bug.cgi?id=24496". - -2. Keyword Restrictions - -Some keywords should only apply in certain circumstances, eg beta1 => -Milestone < -M14, css1 => Component = Style System are possibilities. See -"http://bugzilla.mozilla.org/show_bug.cgi?id=26940". - -3. Whine About Old Votes - -Old votes can just sit on resolved bugs. This is problematic with -duplicates especially. Automatic transferral/removal is not -appropriate since bugs can be reopened, but a whining solution might -work. See "http://bugzilla.mozilla.org/show_bug.cgi?id=27553". - -4. Whine And Warn About Milestone Mismatches - -Here's a fun one. Bug X (M17) depends on Bug Y (M15). Bug Y gets moved -out to M19. The notification to the assignee of Bug X gets ignored (of -course) and Bug X is now due to be fixed before one of its blockers. - -Warnings about this when it is detected as well as whining about it in -email would help bring these issues to the attention of people sooner. - -Note that this would be less of a problem if we didn't have so many -tracking bugs since they aren't updated that often and often have this -problem. - -See "http://bugzilla.mozilla.org/show_bug.cgi?id=16743". - -
- -
- Bugzilla 3.0 - One day, Bugzilla 3.0 will have lots of cool stuff. -
- + The future of Bugzilla is Bugzilla 3.0. Unfortunately, I do + not have more information about it right now, and most of what + went into the "future" section is now present. That stuff was + blue-sky a year ago; MattyT should have me a new document + sometime... -- cgit v1.2.3-24-g4f1b