diff --git a/confirmhelp.html b/confirmhelp.html deleted file mode 100644 index 20ccfd402fef9e96754f268eebcdc205b3b7780c..0000000000000000000000000000000000000000 --- a/confirmhelp.html +++ /dev/null @@ -1,168 +0,0 @@ -<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> -<html><head> - -<!-- - The contents of this file are subject to the Mozilla Public - License Version 1.1 (the "License"); you may not use this file - except in compliance with the License. You may obtain a copy of - the License at http://www.mozilla.org/MPL/ - - Software distributed under the License is distributed on an "AS - IS" basis, WITHOUT WARRANTY OF ANY KIND, either express or - implied. See the License for the specific language governing - rights and limitations under the License. - - The Original Code is the Bugzilla Bug Tracking System. - - The Initial Developer of the Original Code is Netscape Communications - Corporation. Portions created by Netscape are - Copyright (C) 2000 Netscape Communications Corporation. All - Rights Reserved. - - Contributor(s): Terry Weissman <terry@mozilla.org> ---> - -<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> -<title>Understanding the UNCONFIRMED state, and other recent changes</title> -</head> - -<body> -<h1>Understanding the UNCONFIRMED state, and other recent changes</h1> - -<p> -[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.] -</p> - -<p> - -New bugs in some products will now show up in a new state, -UNCONFIRMED. This means that we have nobody has confirmed that the -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.) -</p> - -<p> -The <a href="bug_status.html">page describing bug fields</a> has been -updated to include UNCONFIRMED. -</p> - -<p> -There are two basic ways that a bug can become confirmed (and enter -the NEW) state. -</p> - -<ul> - <li> A user with the appropriate permissions (see below for more on - permissions) decides that the bug is a valid one, and confirms - it. We hope to gather a small army of responsible volunteers - to regularly go through bugs for us.</li> - <li> The bug gathers a certain number of votes. <b>Any</b> valid Bugzilla user may vote for -bugs (each user gets a certain number of bugs); any UNCONFIRMED bug which -gets enough votes becomes automatically confirmed, and enters the NEW state.</li> -</ul> - -<p> -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. -</p> - -<h2>Permissions.</h2> - -<p> -Users now have a certain set of permissions. To see your permissions, -check out the -<a href="userprefs.cgi?bank=permissions">user preferences</a> page. -</p> - -<p> -If you have the "Can confirm a bug" permission, then you will be able -to move UNCONFIRMED bugs into the NEW state. -</p> - -<p> -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. -</p> - -<p> -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. -</p> - -<h2>Other details.</h2> - -<p> -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 -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. -</p> - -<p> -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. -</p> - -<p> -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. -</p> - -<p> -Note that only some products support the UNCONFIRMED state. In other -products, all new bugs will automatically start in the NEW state. -</p> - -<h2>Things still to be done.</h2> - -<p> -There probably ought to be a way to get a bug back into the -UNCONFIRMED state, but there isn't yet. -</p> - -<p> -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. -</p> - -<p> -There should also be a way to automatically promote people to get the -"Can edit all aspects of any bug" permission. -</p> - -<p> -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. -</p> - -<hr> -<p> -<!-- hhmts start --> -Last modified: Sun Apr 14 12:55:14 EST 2002 -<!-- hhmts end --> -</p> -</body> </html> diff --git a/help.html b/help.html deleted file mode 100644 index a7c93cb4574e8c1caf764b2048893bcdb207cdd1..0000000000000000000000000000000000000000 --- a/help.html +++ /dev/null @@ -1,70 +0,0 @@ -<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> -<HTML> -<!-- - The contents of this file are subject to the Mozilla Public - License Version 1.1 (the "License"); you may not use this file - except in compliance with the License. You may obtain a copy of - the License at http://www.mozilla.org/MPL/ - - Software distributed under the License is distributed on an "AS - IS" basis, WITHOUT WARRANTY OF ANY KIND, either express or - implied. See the License for the specific language governing - rights and limitations under the License. - - The Original Code is the Bugzilla Bug Tracking System. - - The Initial Developer of the Original Code is Netscape Communications - Corporation. Portions created by Netscape are - Copyright (C) 1998 Netscape Communications Corporation. All - Rights Reserved. - - Contributor(s): - - Contributor(s): Terry Weissman <terry@mozilla.org> ---> - -<head> -<TITLE>Clue</TITLE> -<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> -</head><body> -<H1>A Clue</H1> -This form will allow you to call up a subset of the bug list. -You should be able to add the URL of the resulting list to -your bookmark file in order to preserve queries. -<p> -The way the query works, if you have nothing checked in a box, -then all values for that field are legal, for example if you checked nothing -in any of the boxes, you would get the entire bug list. -<p> -The default value of this form should correspond roughly to a "personal" -bug list. -<HR> -<H2>Running queries not supported by the pretty boxes</H2> -There is a hacky way to do some searches that aren't supported by the -form. The buglist script will build queries based on the URL, so -you can add other criteria. -<P> -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" -to the URL. -<P> -Here is a list of some of the field names you could use for additional -unsupported searches ... - -<PRE> -version -rep_platform -op_sys -reporter area -bug_file_loc -short_desc -</PRE> -<HR> -<H1>Browser Notes</H1> -<P>Bugzilla uses several non-standard Netscape extentions, but this does not seem -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. - -</body></html> diff --git a/helpemailquery.html b/helpemailquery.html deleted file mode 100644 index 5c4527a78599e5ce2add983b65e4708835ee561f..0000000000000000000000000000000000000000 --- a/helpemailquery.html +++ /dev/null @@ -1,38 +0,0 @@ -<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> -<html> <head> -<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> -<title>Help on searching by email address.</title> -</head> - -<body> -<h1>Help on searching by email address.</h1> - -<p> -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... -</p> - -<p> -To search for bugs associated with an email address: -</p> - -<ul> - <li> Type a portion of an email address into the text field.</li> - <li> Select which fields of the bug you expect that address to be in - the bugs you're looking for.</li> -</ul> - -<p> -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. -</p> - -<p> -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. -</p> - -</body> </html> diff --git a/how_to_mail.html b/how_to_mail.html deleted file mode 100644 index b60c41688836c5899a3eda0b31036fb7c4c9acb5..0000000000000000000000000000000000000000 --- a/how_to_mail.html +++ /dev/null @@ -1,90 +0,0 @@ -<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> -<HTML> -<head> - -<!-- - The contents of this file are subject to the Mozilla Public - License Version 1.1 (the "License"); you may not use this file - except in compliance with the License. You may obtain a copy of - the License at http://www.mozilla.org/MPL/ - - Software distributed under the License is distributed on an "AS - IS" basis, WITHOUT WARRANTY OF ANY KIND, either express or - implied. See the License for the specific language governing - rights and limitations under the License. - - The Original Code is the Bugzilla Bug Tracking System. - - The Initial Developer of the Original Code is Netscape Communications - Corporation. Portions created by Netscape are - Copyright (C) 1998 Netscape Communications Corporation. All - Rights Reserved. - - Contributor(s): - - Contributor(s): Terry Weissman <terry@mozilla.org> ---> - - -<TITLE>How to Mail to bugzilla</TITLE> -<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> -</head> -<body> - -<H1>THIS DOESN'T WORK RIGHT NOW. Coming someday.</H1> - -Mailing to "bugzilla" will be piped through a script which examines -your message, stripping out control lines, and passing the rest of the -message in as the description of a new bug. The control lines look like: <P> - -<PRE> -@FIELD-LABEL VALUE - LABEL Legal Values - Priority critical major normal minor trivial - Type BUG RFE - Product Cheddar - Platform PC X-Windows Macintosh All - Area CODE JAVA TEST BUILD UI PERF - Version version 2.0b1 2.0b2 2.0b2 2.0b4 2.1a0 2.1a1 2.1b0 2.1b1 2.1b2 - OS Windows 3.1 Windows 95 Windows NT System 7 System 7.5 - AIX BSDI HP-UX IRIX Linux OSF/1 Solaris SunOS other - Summary -anything- - URL -anything- - Assign someone in eng - - -and - -@description - This tells the bug parse to stop looking for control lines, - allowing the bug description to contain lines which start with @ -</PRE> - -There are default values for all these fields. If you don't specify a -Summary, the subject of the mail message is used. <P> - -If you specify an illegal value, the default value is used, the -bug is assigned to you, and the answerback message will describe -the error. <P> - -After the bug is posted, you will get mail verifying the posting -and informing you of the bug number if you wish to fix any -mistakes made by the auto-processor. <P> - -EXAMPLE: <P> - - -<PRE> - % Mail bugzilla - Subject: WinFE crashes with GPF when I pour beer on my keyboard - @priority critical - @platform PC - @assign troy - - After the beer bash I emptied the rest of the keg onto my keyboard - and my sharp build of Navigator got a GPF. - . - -</PRE> - -</body></html> diff --git a/notargetmilestone.html b/notargetmilestone.html deleted file mode 100644 index 1cedb1acaa454ff4064f3cbc72c5c5fce9d16084..0000000000000000000000000000000000000000 --- a/notargetmilestone.html +++ /dev/null @@ -1,16 +0,0 @@ -<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> -<html> <head> -<title>No target milestones</title> -</head> - -<body> -<h1>No target milestones.</h1> - -<p> -No target milestones have been defined for this product. You can set -the Target Milestone field to things, but there is not currently any -agreed definition of what the milestones are. -</p> - -</body> -</html>