summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
-rw-r--r--confirmhelp.html168
-rw-r--r--help.html70
-rw-r--r--helpemailquery.html38
-rw-r--r--how_to_mail.html90
-rw-r--r--notargetmilestone.html16
5 files changed, 0 insertions, 382 deletions
diff --git a/confirmhelp.html b/confirmhelp.html
deleted file mode 100644
index 20ccfd402..000000000
--- 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 a7c93cb45..000000000
--- 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 "&amp;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 5c4527a78..000000000
--- 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 b60c41688..000000000
--- 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 1cedb1aca..000000000
--- 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>