diff options
Diffstat (limited to 'docs/html/programadmin.html')
| -rw-r--r-- | docs/html/programadmin.html | 1107 |
1 files changed, 1107 insertions, 0 deletions
diff --git a/docs/html/programadmin.html b/docs/html/programadmin.html new file mode 100644 index 000000000..2ebb4e126 --- /dev/null +++ b/docs/html/programadmin.html @@ -0,0 +1,1107 @@ +<HTML +><HEAD +><TITLE +>Product, Component, Milestone, and Version + Administration</TITLE +><META +NAME="GENERATOR" +CONTENT="Modular DocBook HTML Stylesheet Version 1.61 +"><LINK +REL="HOME" +TITLE="The Bugzilla Guide" +HREF="index.html"><LINK +REL="UP" +TITLE="Administering Bugzilla" +HREF="administration.html"><LINK +REL="PREVIOUS" +TITLE="User Administration" +HREF="useradmin.html"><LINK +REL="NEXT" +TITLE="Bugzilla Security" +HREF="security.html"></HEAD +><BODY +CLASS="SECTION" +BGCOLOR="#FFFFFF" +TEXT="#000000" +LINK="#0000FF" +VLINK="#840084" +ALINK="#0000FF" +><DIV +CLASS="NAVHEADER" +><TABLE +WIDTH="100%" +BORDER="0" +CELLPADDING="0" +CELLSPACING="0" +><TR +><TH +COLSPAN="3" +ALIGN="center" +>The Bugzilla Guide</TH +></TR +><TR +><TD +WIDTH="10%" +ALIGN="left" +VALIGN="bottom" +><A +HREF="useradmin.html" +>Prev</A +></TD +><TD +WIDTH="80%" +ALIGN="center" +VALIGN="bottom" +>Chapter 4. Administering Bugzilla</TD +><TD +WIDTH="10%" +ALIGN="right" +VALIGN="bottom" +><A +HREF="security.html" +>Next</A +></TD +></TR +></TABLE +><HR +ALIGN="LEFT" +WIDTH="100%"></DIV +><DIV +CLASS="SECTION" +><H1 +CLASS="SECTION" +><A +NAME="PROGRAMADMIN" +>4.3. Product, Component, Milestone, and Version + Administration</A +></H1 +><TABLE +BORDER="0" +WIDTH="100%" +CELLSPACING="0" +CELLPADDING="0" +CLASS="EPIGRAPH" +><TR +><TD +WIDTH="45%" +> </TD +><TD +WIDTH="45%" +ALIGN="LEFT" +VALIGN="TOP" +><I +><P +><I +>Dear Lord, we have to get our users to do WHAT?</I +></P +></I +></TD +></TR +></TABLE +><DIV +CLASS="SECTION" +><H2 +CLASS="SECTION" +><A +NAME="PRODUCTS" +>4.3.1. Products</A +></H2 +><FONT +COLOR="RED" +>Formerly, and in some spots still, called + "Programs"</FONT +><P +> <A +HREF="glossary.html#GLOSS_PRODUCT" +><I +CLASS="GLOSSTERM" +>Products</I +></A +> are + the broadest category in Bugzilla, and you should have the + least of these. If your company makes computer games, you + should have one product per game, and possibly a few special + products (website, meetings...) + </P +><P +> A Product (formerly called "Program", and still referred to + that way in some portions of the source code) controls some + very important functions. The number of "votes" available for + users to vote for the most important bugs is set per-product, + as is the number of votes required to move a bug automatically + from the UNCONFIRMED status to the NEW status. One can close + a Product for further bug entry and define various Versions + available from the Edit product screen. + </P +><P +>To create a new product:</P +><P +></P +><OL +TYPE="1" +><LI +><P +> Select "components" from the yellow footer + </P +><DIV +CLASS="TIP" +><P +></P +><TABLE +CLASS="TIP" +WIDTH="90%" +BORDER="0" +><TR +><TD +WIDTH="25" +ALIGN="CENTER" +VALIGN="TOP" +><IMG +SRC="../images/tip.gif" +HSPACE="5" +ALT="Tip"></TD +><TD +ALIGN="LEFT" +VALIGN="TOP" +><P +> It may seem counterintuitive to click "components" when + you want to edit the properties associated with + Products. This is one of a long list of things we want + in Bugzilla 3.0... + </P +></TD +></TR +></TABLE +></DIV +></LI +><LI +><P +> Select the "Add" link to the right of "Add a new product". + </P +></LI +><LI +><P +> Enter the name of the product and a description. The + Description field is free-form. + </P +></LI +></OL +><DIV +CLASS="TIP" +><P +></P +><TABLE +CLASS="TIP" +WIDTH="100%" +BORDER="0" +><TR +><TD +WIDTH="25" +ALIGN="CENTER" +VALIGN="TOP" +><IMG +SRC="../images/tip.gif" +HSPACE="5" +ALT="Tip"></TD +><TD +ALIGN="LEFT" +VALIGN="TOP" +><P +> Don't worry about the "Closed for bug entry", "Maximum Votes + per person", "Maximum votes a person can put on a single + bug", "Number of votes a bug in this Product needs to + automatically get out of the UNCOMFIRMED state", and + "Version" options yet. We'll cover those in a few moments. + </P +></TD +></TR +></TABLE +></DIV +></DIV +><DIV +CLASS="SECTION" +><H2 +CLASS="SECTION" +><A +NAME="COMPONENTS" +>4.3.2. Components</A +></H2 +><P +> Components are subsections of a Product. + + <DIV +CLASS="EXAMPLE" +><A +NAME="AEN1279" +></A +><P +><B +>Example 4-1. Creating some Components</B +></P +><DIV +CLASS="INFORMALEXAMPLE" +><A +NAME="AEN1281" +></A +><P +></P +><P +> The computer game you are designing may have a "UI" + component, an "API" component, a "Sound System" + component, and a "Plugins" component, each overseen by + a different programmer. It often makes sense to divide + Components in Bugzilla according to the natural + divisions of responsibility within your Product or + company. + </P +><P +></P +></DIV +></DIV +> Each component has a owner and (if you turned it on + in the parameters), a QA Contact. The owner should be the + primary person who fixes bugs in that component. The QA + Contact should be the person who will ensure these bugs are + completely fixed. The Owner, QA Contact, and Reporter will get + email when new bugs are created in this Component and when + these bugs change. Default Owner and Default QA Contact fields + only dictate the <EM +>default assignments</EM +>; the + Owner and QA Contact fields in a bug are otherwise unrelated + to the Component. + </P +><P +> To create a new Component: + </P +><P +></P +><OL +TYPE="1" +><LI +><P +> Select the "Edit components" link from the "Edit product" + page + </P +></LI +><LI +><P +> Select the "Add" link to the right of the "Add a new + component" text on the "Select Component" page. + </P +></LI +><LI +><P +> Fill out the "Component" field, a short "Description", and + the "Initial Owner". The Component and Description fields + are free-form; the "Initial Owner" field must be that of a + user ID already existing in the database. If the initial + owner does not exist, Bugzilla will refuse to create the + component. + <DIV +CLASS="TIP" +><P +></P +><TABLE +CLASS="TIP" +WIDTH="90%" +BORDER="0" +><TR +><TD +WIDTH="25" +ALIGN="CENTER" +VALIGN="TOP" +><IMG +SRC="../images/tip.gif" +HSPACE="5" +ALT="Tip"></TD +><TD +ALIGN="LEFT" +VALIGN="TOP" +><P +> Is your "Default Owner" a user who is not yet in the + database? No problem. + <P +></P +><OL +TYPE="a" +><LI +><P +> Select the "Log out" link on the footer of the + page. + </P +></LI +><LI +><P +> Select the "New Account" link on the footer of + the "Relogin" page + </P +></LI +><LI +><P +> Type in the email address of the default owner + you want to create in the "E-mail address" + field, and her full name in the "Real name" + field, then select the "Submit Query" button. + </P +></LI +><LI +><P +> Now select "Log in" again, type in your login + information, and you can modify the product to + use the Default Owner information you require. + </P +></LI +></OL +> + </P +></TD +></TR +></TABLE +></DIV +> + </P +></LI +><LI +><P +> Either Edit more components or return to the Bugzilla + Query Page. To return to the Product you were editing, you + must select the Components link as before. + </P +></LI +></OL +></DIV +><DIV +CLASS="SECTION" +><H2 +CLASS="SECTION" +><A +NAME="VERSIONS" +>4.3.3. Versions</A +></H2 +><P +> Versions are the revisions of the product, such as "Flinders + 3.1", "Flinders 95", and "Flinders 2000". Using Versions + helps you isolate code changes and are an aid in reporting. + + <DIV +CLASS="EXAMPLE" +><A +NAME="AEN1308" +></A +><P +><B +>Example 4-2. Common Use of Versions</B +></P +><DIV +CLASS="INFORMALEXAMPLE" +><A +NAME="AEN1310" +></A +><P +></P +><P +> A user reports a bug against Version "Beta 2.0" of your + product. The current Version of your software is + "Release Candidate 1", and no longer has the bug. This + will help you triage and classify bugs according to + their relevance. It is also possible people may report + bugs against bleeding-edge beta versions that are not + evident in older versions of the software. This can + help isolate code changes that caused the bug + </P +><P +></P +></DIV +></DIV +> + <DIV +CLASS="EXAMPLE" +><A +NAME="AEN1312" +></A +><P +><B +>Example 4-3. A Different Use of Versions</B +></P +><DIV +CLASS="INFORMALEXAMPLE" +><A +NAME="AEN1314" +></A +><P +></P +><P +> This field has been used to good effect by an online + service provider in a slightly different way. They had + three versions of the product: "Production", "QA", and + "Dev". Although it may be the same product, a bug in + the development environment is not normally as critical + as a Production bug, nor does it need to be reported + publicly. When used in conjunction with Target + Milestones, one can easily specify the environment where + a bug can be reproduced, and the Milestone by which it + will be fixed. + </P +><P +></P +></DIV +></DIV +> + </P +><P +> To create and edit Versions: + </P +><P +></P +><OL +TYPE="1" +><LI +><P +> From the "Edit product" screen, select "Edit Versions" + </P +></LI +><LI +><P +> You will notice that the product already has the default + version "undefined". If your product doesn't use version + numbers, you may want to leave this as it is or edit it so + that it is "---". You can then go back to the edit + versions page and add new versions to your product. + </P +><P +> Otherwise, click the "Add" button to the right of the "Add + a new version" text. + </P +></LI +><LI +><P +> Enter the name of the Version. This can be free-form + characters up to the limit of the text box. Then select + the "Add" button. + </P +></LI +><LI +><P +> At this point you can select "Edit" to edit more Versions, + or return to the "Query" page, from which you can navigate + back to the product through the "components" link at the + foot of the Query page. + </P +></LI +></OL +></DIV +><DIV +CLASS="SECTION" +><H2 +CLASS="SECTION" +><A +NAME="MILESTONES" +>4.3.4. Milestones</A +></H2 +><P +> Milestones are "targets" that you plan to get a bug fixed by. + For example, you have a bug that you plan to fix for your 3.0 + release, it would be assigned the milestone of 3.0. Or, you + have a bug that you plan to fix for 2.8, this would have a + milestone of 2.8. + </P +><DIV +CLASS="NOTE" +><P +></P +><TABLE +CLASS="NOTE" +WIDTH="100%" +BORDER="0" +><TR +><TD +WIDTH="25" +ALIGN="CENTER" +VALIGN="TOP" +><IMG +SRC="../images/note.gif" +HSPACE="5" +ALT="Note"></TD +><TD +ALIGN="LEFT" +VALIGN="TOP" +><P +> Milestone options will only appear for a Product if you + turned the "usetargetmilestone" field in the "Edit + Parameters" screen "On". + </P +></TD +></TR +></TABLE +></DIV +><P +> To create new Milestones, set Default Milestones, and set + Milestone URL: + </P +><P +></P +><OL +TYPE="1" +><LI +><P +> Select "edit milestones" + </P +></LI +><LI +><P +> Select "Add" to the right of the "Add a new milestone" + text + </P +></LI +><LI +><P +> Enter the name of the Milestone in the "Milestone" field. + You can optionally set the "Sortkey", which is a positive + or negative number (-255 to 255) that defines where in the + list this particular milestone appears. Select "Add". + </P +><DIV +CLASS="EXAMPLE" +><A +NAME="AEN1340" +></A +><P +><B +>Example 4-4. Using SortKey with Target Milestone</B +></P +><DIV +CLASS="INFORMALEXAMPLE" +><A +NAME="AEN1342" +></A +><P +></P +><P +> Let's say you create a target milestone called + "Release 1.0", with Sortkey set to "0". Later, you + realize that you will have a public beta, called + "Beta1". You can create a Milestone called "Beta1", + with a Sortkey of "-1" in order to ensure people will + see the Target Milestone of "Beta1" earlier on the + list than "Release 1.0" + </P +><P +></P +></DIV +></DIV +></LI +><LI +><P +> If you want to add more milestones, select the "Edit" + link. If you don't, well shoot, you have to go back to the + "query" page and select "components" again, and make your + way back to the Product you were editing. + <DIV +CLASS="NOTE" +><P +></P +><TABLE +CLASS="NOTE" +WIDTH="90%" +BORDER="0" +><TR +><TD +WIDTH="25" +ALIGN="CENTER" +VALIGN="TOP" +><IMG +SRC="../images/note.gif" +HSPACE="5" +ALT="Note"></TD +><TD +ALIGN="LEFT" +VALIGN="TOP" +><P +> This is another in the list of unusual user interface + decisions that we'd like to get cleaned up. Shouldn't + there be a link to the effect of "edit the Product I + was editing when I ended up here"? In any case, + clicking "components" in the footer takes you back to + the "Select product" screen, from which you can begin + editing your product again. + </P +></TD +></TR +></TABLE +></DIV +> + </P +></LI +><LI +><P +> From the Edit product screen again (once you've made your + way back), enter the URL for a description of what your + milestones are for this product in the "Milestone URL" + field. It should be of the format + "http://www.foo.com/bugzilla/product_milestones.html" + </P +><P +> Some common uses of this field include product + descriptions, product roadmaps, and of course a simple + description of the meaning of each milestone. + </P +></LI +><LI +><P +> If you're using Target Milestones, the "Default Milestone" + field must have some kind of entry. If you really don't + care if people set coherent Target Milestones, simply + leave this at the default, "---". However, controlling + and regularly updating the Default Milestone field is a + powerful tool when reporting the status of projects. + </P +><P +>Select the "Update" button when you are done.</P +></LI +></OL +></DIV +><DIV +CLASS="SECTION" +><H2 +CLASS="SECTION" +><A +NAME="VOTING" +>4.3.5. Voting</A +></H2 +><P +> The concept of "voting" is a poorly understood, yet powerful + feature for the management of open-source projects. Each user + is assigned so many Votes per product, which they can freely + reassign (or assign multiple votes to a single bug). This + allows developers to gauge user need for a particular + enhancement or bugfix. By allowing bugs with a certain number + of votes to automatically move from "UNCONFIRMED" to "NEW", + users of the bug system can help high-priority bugs garner + attention so they don't sit for a long time awaiting triage. + </P +><P +> The daunting challenge of Votes is deciding where you draw the + line for a "vocal majority". If you only have a user base of + 100 users, setting a low threshold for bugs to move from + UNCONFIRMED to NEW makes sense. As the Bugzilla user base + expands, however, these thresholds must be re-evaluated. You + should gauge whether this feature is worth the time and close + monitoring involved, and perhaps forego implementation until + you have a critical mass of users who demand it. + </P +><P +>To modify Voting settings:</P +><P +></P +><OL +TYPE="1" +><LI +><P +> Navigate to the "Edit product" screen for the Product you + wish to modify + </P +></LI +><LI +><P +> Set "Maximum Votes per person" to your calculated value. + Setting this field to "0" disables voting. + </P +></LI +><LI +><P +> Set "Maximum Votes a person can put on a single bug" to + your calculated value. It should probably be some number + lower than the "Maximum votes per person". Setting this + field to "0" disables voting, but leaves the voting + options open to the user. This is confusing. + </P +></LI +><LI +><P +> Set "Number of votes a bug in this product needs to + automatically get out of the UNCONFIRMED state" to your + calculated number. Setting this field to "0" disables + the automatic move of bugs from UNCONFIRMED to NEW. Some + people advocate leaving this at "0", but of what use are + Votes if your Bugzilla user base is unable to affect which + bugs appear on Development radar? + <DIV +CLASS="TIP" +><P +></P +><TABLE +CLASS="TIP" +WIDTH="90%" +BORDER="0" +><TR +><TD +WIDTH="25" +ALIGN="CENTER" +VALIGN="TOP" +><IMG +SRC="../images/tip.gif" +HSPACE="5" +ALT="Tip"></TD +><TD +ALIGN="LEFT" +VALIGN="TOP" +><P +> You should probably set this number to higher than a + small coalition of Bugzilla users can influence it. + Most sites use this as a "referendum" mechanism -- if + users are able to vote a bug out of UNCONFIRMED, it is + a <EM +>really</EM +> bad bug! + </P +></TD +></TR +></TABLE +></DIV +> + </P +></LI +><LI +><P +> Once you have adjusted the values to your preference, + select the "Update" button. + </P +></LI +></OL +></DIV +><DIV +CLASS="SECTION" +><H2 +CLASS="SECTION" +><A +NAME="GROUPS" +>4.3.6. Groups and Group Security</A +></H2 +><P +> Groups can be very useful in bugzilla, because they allow + users to isolate bugs or products that should only be seen by + certain people. Groups can also be a complicated minefield of + interdependencies and weirdness if mismanaged. + + <DIV +CLASS="EXAMPLE" +><A +NAME="AEN1376" +></A +><P +><B +>Example 4-5. When to Use Group Security</B +></P +><DIV +CLASS="INFORMALEXAMPLE" +><A +NAME="AEN1378" +></A +><P +></P +><P +> Many Bugzilla sites isolate "Security-related" bugs from + all other bugs. This way, they can have a fix ready + before the security vulnerability is announced to the + world. You can create a "Security" product which, by + default, has no members, and only add members to the + group (in their individual User page, as described under + User Administration) who should have priveleged access + to "Security" bugs. Alternately, you may create a Group + independently of any Product, and change the Group mask + on individual bugs to restrict access to members only of + certain Groups. + </P +><P +></P +></DIV +></DIV +> Groups only work if you enable the "usebuggroups" + paramater. In addition, if the "usebuggroupsentry" parameter + is "On", one can restrict access to products by groups, so + that only members of a product group are able to view bugs + within that product. Group security in Bugzilla can be divided + into two categories: Generic and Product-Based. + </P +><DIV +CLASS="NOTE" +><P +></P +><TABLE +CLASS="NOTE" +WIDTH="100%" +BORDER="0" +><TR +><TD +WIDTH="25" +ALIGN="CENTER" +VALIGN="TOP" +><IMG +SRC="../images/note.gif" +HSPACE="5" +ALT="Note"></TD +><TD +ALIGN="LEFT" +VALIGN="TOP" +><P +> Groups in Bugzilla are a complicated beast that evolved out + of very simple user permission bitmasks, apparently itself + derived from common concepts in UNIX access controls. A + "bitmask" is a fixed-length number whose value can describe + one, and only one, set of states. For instance, UNIX file + permissions are assigned bitmask values: "execute" has a + value of 1, "write" has a value of 2, and "read" has a + value of 4. Add them together, and a file can be read, + written to, and executed if it has a bitmask of "7". (This + is a simplified example -- anybody who knows UNIX security + knows there is much more to it than this. Please bear with + me for the purpose of this note.) The only way a bitmask + scheme can work is by doubling the bit count for each value. + Thus if UNIX wanted to offer another file permission, the + next would have to be a value of 8, then the next 16, the + next 32, etc. + </P +><P +> Similarly, Bugzilla offers a bitmask to define group + permissions, with an internal limit of 64. Several are + already occupied by built-in permissions. The way around + this limitation is to avoid assigning groups to products if + you have many products, avoid bloating of group lists, and + religiously prune irrelevant groups. In reality, most + installations of Bugzilla support far fewer than 64 groups, + so this limitation has not hit for most sites, but it is on + the table to be revised for Bugzilla 3.0 because it + interferes with the security schemes of some administrators. + </P +></TD +></TR +></TABLE +></DIV +><P +> To enable Generic Group Security ("usebuggroups"): + </P +><P +></P +><OL +TYPE="1" +><LI +><P +> Turn "On" "usebuggroups" in the "Edit Parameters" screen. + </P +></LI +><LI +><P +> You will generally have no groups set up. Select the + "groups" link in the footer. + </P +></LI +><LI +><P +> Take a moment to understand the instructions on the "Edit + Groups" screen. Once you feel confident you understand + what is expected of you, select the "Add Group" link. + </P +></LI +><LI +><P +> Fill out the "New Name" (remember, no spaces!), "New + Description", and "New User RegExp" fields. "New User + RegExp" allows you to automatically place all users who + fulfill the Regular Expression into the new group. + + <DIV +CLASS="EXAMPLE" +><A +NAME="AEN1393" +></A +><P +><B +>Example 4-6. Creating a New Group</B +></P +><DIV +CLASS="INFORMALEXAMPLE" +><A +NAME="AEN1395" +></A +><P +></P +><P +> I created a group called DefaultGroup with a + description of <SPAN +CLASS="QUOTE" +>"This is simply a group to play + with"</SPAN +>, and a New User RegExp of <SPAN +CLASS="QUOTE" +>".*@mydomain.tld"</SPAN +>. + This new group automatically includes all Bugzilla + users with "@mydomain.tld" at the end of their user id. + When I finished, my new group was assigned bit #128. + </P +><P +></P +></DIV +></DIV +> When you have finished, select the Add + button. + </P +></LI +></OL +><P +> To enable Product-Based Group Security (usebuggroupsentry): + </P +><DIV +CLASS="WARNING" +><P +></P +><TABLE +CLASS="WARNING" +WIDTH="100%" +BORDER="0" +><TR +><TD +WIDTH="25" +ALIGN="CENTER" +VALIGN="TOP" +><IMG +SRC="../images/warning.gif" +HSPACE="5" +ALT="Warning"></TD +><TD +ALIGN="LEFT" +VALIGN="TOP" +><P +> Don't forget that you only have 64 groups masks available, + total, for your installation of Bugzilla! If you plan on + having more than 50 products in your individual Bugzilla + installation, and require group security for your products, + you should consider either running multiple Bugzillas or + using Generic Group Security instead of Product-Based + ("usebuggroupsentry") Group Security. + </P +></TD +></TR +></TABLE +></DIV +><P +></P +><OL +TYPE="1" +><LI +><P +> Turn "On" "usebuggroups" and "usebuggroupsentry" in the + "Edit Parameters" screen. + </P +><DIV +CLASS="WARNING" +><P +></P +><TABLE +CLASS="WARNING" +WIDTH="90%" +BORDER="0" +><TR +><TD +WIDTH="25" +ALIGN="CENTER" +VALIGN="TOP" +><IMG +SRC="../images/warning.gif" +HSPACE="5" +ALT="Warning"></TD +><TD +ALIGN="LEFT" +VALIGN="TOP" +><P +> "usebuggroupsentry" has the capacity to prevent the + administrative user from directly altering bugs because + of conflicting group permissions. If you plan on using + "usebuggroupsentry", you should plan on restricting + administrative account usage to administrative duties + only. In other words, manage bugs with an unpriveleged + user account, and manage users, groups, Products, etc. + with the administrative account. + </P +></TD +></TR +></TABLE +></DIV +></LI +><LI +><P +> You will generally have no Groups set up, unless you + enabled "usebuggroupsentry" prior to creating any + Products. To create "Generic Group Security" groups, + follow the instructions given above. To create + Product-Based Group security, simply follow the + instructions for creating a new Product. If you need to + add users to these new groups as you create them, you will + find the option to add them to the group available under + the "Edit User" screens. + </P +></LI +></OL +></DIV +></DIV +><DIV +CLASS="NAVFOOTER" +><HR +ALIGN="LEFT" +WIDTH="100%"><TABLE +WIDTH="100%" +BORDER="0" +CELLPADDING="0" +CELLSPACING="0" +><TR +><TD +WIDTH="33%" +ALIGN="left" +VALIGN="top" +><A +HREF="useradmin.html" +>Prev</A +></TD +><TD +WIDTH="34%" +ALIGN="center" +VALIGN="top" +><A +HREF="index.html" +>Home</A +></TD +><TD +WIDTH="33%" +ALIGN="right" +VALIGN="top" +><A +HREF="security.html" +>Next</A +></TD +></TR +><TR +><TD +WIDTH="33%" +ALIGN="left" +VALIGN="top" +>User Administration</TD +><TD +WIDTH="34%" +ALIGN="center" +VALIGN="top" +><A +HREF="administration.html" +>Up</A +></TD +><TD +WIDTH="33%" +ALIGN="right" +VALIGN="top" +>Bugzilla Security</TD +></TR +></TABLE +></DIV +></BODY +></HTML +>
\ No newline at end of file |