Actual Results: What the application did after performing the above steps. +
@@ -318,6 +318,7 @@ pointer -- you'll see their visible manifestations, such as the segfault when the application finally crashes. Severe software problems can manifest themselves in superficially trivial ways. File them anyway.
+
2. How and Why to Write Good Bug Summaries diff --git a/confirmhelp.html b/confirmhelp.html index 1dad97302..20ccfd402 100644 --- a/confirmhelp.html +++ b/confirmhelp.html @@ -1,4 +1,5 @@ -
+ + +[This document is aimed primarily at people who have used Bugzilla before the UNCONFIRMED state was implemented. It might be helpful for newer users as well.] +
@@ -39,60 +43,67 @@ bug is real. Very busy engineers will probably generally ignore UNCONFIRMED that have been assigned to them, until they have been confirmed in one way or another. (Engineers with more time will hopefully glance over their UNCONFIRMED bugs regularly.) +
- The page describing bug fields has been updated to include UNCONFIRMED. -
+
+There are two basic ways that a bug can become confirmed (and enter the NEW) state. +
One implication of this is that it is worth your time to search the bug system for duplicates of your bug to vote on them, before submitting your own bug. If we can spread around knowledge of this fact, it ought to help cut down the number of duplicate bugs in the system. +
Users now have a certain set of permissions. To see your permissions, check out the user preferences page. +
- If you have the "Can confirm a bug" permission, then you will be able to move UNCONFIRMED bugs into the NEW state. +
- If you have the "Can edit all aspects of any bug" permission, then you can tweak anything about any bug. If not, you may only edit those bugs that you have submitted, or that you have assigned to you (or qa-assigned to you). However, anyone may add a comment to any bug. +
- Some people (initially, the initial owners and initial qa-contacts for components in the system) have the ability to give the above two permissions to other people. So, if you really feel that you ought to have one of these permissions, a good person to ask (via private email, please!) is the person who is assigned a relevant bug. +
An initial stab was taken to decide who would be given which of the above permissions. This was determined by some simple heurstics of who was assigned bugs, and who the default owners of bugs were, and a @@ -100,54 +111,58 @@ look at people who seem to have submitted several bugs that appear to have been interesting and valid. Inevitably, we have failed to give someone the permissions they deserve. Please don't take it personally; just bear with us as we shake out the new system. +
- - People with one of the two bits above can easily confirm their own bugs, so bugs they submit will actually start out in the NEW state. They can override this when submitting a bug. +
- People can ACCEPT or RESOLVE a bug assigned to them, even if they aren't allowed to confirm it. However, the system remembers, and if the bug gets REOPENED or reassigned to someone else, it will revert back to the UNCONFIRMED state. If the bug has ever been confirmed, then REOPENing or reassigning will cause it to go to the NEW or REOPENED state. +
- Note that only some products support the UNCONFIRMED state. In other products, all new bugs will automatically start in the NEW state. +
There probably ought to be a way to get a bug back into the UNCONFIRMED state, but there isn't yet. +
- If a person has submitted several bugs that get confirmed, then this is probably a person who understands the system well, and deserves the "Can confirm a bug" permission. This kind of person should be detected and promoted automatically. +
- There should also be a way to automatically promote people to get the "Can edit all aspects of any bug" permission. +
- The "enter a new bug" page needs to be revamped with easy ways for new people to educate themselves on the benefit of searching for a bug like the one they're about to submit and voting on it, rather than adding a new useless duplicate. +
-Last modified: Wed Feb 16 21:04:56 2000 +Last modified: Sun Apr 14 12:55:14 EST 2002 +
diff --git a/defparams.pl b/defparams.pl index d88938f3c..9189b85a7 100644 --- a/defparams.pl +++ b/defparams.pl @@ -347,7 +347,7 @@ DefParam("mostfreqthreshold", DefParam("mybugstemplate", "This is the URL to use to bring up a simple 'all of my bugs' list for a user. %userid% will get replaced with the login name of a user.", "t", - "buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&email1=%userid%&emailtype1=exact&emailassigned_to1=1&emailreporter1=1"); + "buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&email1=%userid%&emailtype1=exact&emailassigned_to1=1&emailreporter1=1"); diff --git a/globals.pl b/globals.pl index 560e0c4ae..32e24878f 100644 --- a/globals.pl +++ b/globals.pl @@ -1051,7 +1051,7 @@ sub quoteUrls { my $num = $4; $item = value_quote($item); # Not really necessary, since we know # there's no special chars in it. - $item = qq{$item}; + $item = qq{$item}; $things[$count++] = $item; } while ($text =~ s/\*\*\* This bug has been marked as a duplicate of (\d+) \*\*\*/"##$count##"/ei) { diff --git a/help.html b/help.html index d84bbfd45..a7c93cb45 100644 --- a/help.html +++ b/help.html @@ -1,3 +1,4 @@ + +For example, if you wanted to see all bugs reported against the X platform and assigned to jwz, you could ask for all bugs assign to jwz, then -edit the URL in the "Location" box, adding the clause "&rep_platform=X-Windows" +edit the URL in the "Location" box, adding the clause "&rep_platform=X-Windows" to the URL.
Here is a list of some of the field names you could use for additional @@ -63,4 +67,4 @@ to case any problem with other browsers. The lynx browser does work, but lynx seems to cache results of a .cgi. You'll sometimes need to press CONTROL-R to reload the screen to see an update. - + diff --git a/helpemailquery.html b/helpemailquery.html index 622e3aa45..5c4527a78 100644 --- a/helpemailquery.html +++ b/helpemailquery.html @@ -1,36 +1,38 @@ +
+This used to be simpler, but not very powerful. Now it's really powerful and useful, but it may not be obvious how to use it... +
- To search for bugs associated with an email address: +
- You can look for up to two different email addresses; if you specify both, then only bugs which match both will show up. This is useful to find bugs that were, for example, created by Ralph and assigned to Fred. +
- You can also use the drop down menus to specify whether you want to match addresses by doing a substring match, by using regular expressions, or by exactly matching a fully specified email address. - - +
diff --git a/how_to_mail.html b/how_to_mail.html index 3ee5b205d..b60c41688 100644 --- a/how_to_mail.html +++ b/how_to_mail.html @@ -1,4 +1,6 @@ + + - -
-
+
+
+
By default, the following fields are searched: Summary, Keywords, Product, Component, Status Whiteboard. If a word looks like a part of a URL, that field is included in the search, too. -
+
Use the powerful Bugzilla Query Form for advanced queries. +
- - - - - diff --git a/quicksearchhack.html b/quicksearchhack.html index 70dcb4b55..17c21e955 100644 --- a/quicksearchhack.html +++ b/quicksearchhack.html @@ -1,31 +1,35 @@ + +Type in one or more words (or word fragments) to search for: +
- -