Skip to content

bugzilla
bugzilla
Commit b771be6f authored by gerv%gerv.net's avatar gerv%gerv.net
Browse files
Options

Bug 170213 - CVS remove old and obsolete HTML files. "Patch" by gerv; a=myk.

parent e7e29be9
Hide whitespace changes
Inline Side-by-side
Showing with 0 additions and 382 deletions
confirmhelp.html deleted 100644 → 0
View file @ e7e29be9
<!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>
help.html deleted 100644 → 0
View file @ e7e29be9
<!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>
helpemailquery.html deleted 100644 → 0
View file @ e7e29be9
<!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>
how_to_mail.html deleted 100644 → 0
View file @ e7e29be9
<!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>
notargetmilestone.html deleted 100644 → 0
View file @ e7e29be9
<!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>
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment