1
<!-- <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook V4.1//EN"> -->
4
<title>Using Bugzilla</title>
6
<section id="using-intro">
7
<title>Introduction</title>
8
<para>This section contains information for end-users of Bugzilla. There
9
is a Bugzilla test installation, called
10
<ulink url="http://landfill.bugzilla.org/">Landfill</ulink>, which you are
11
welcome to play with (if it's up). However, not all of the Bugzilla
12
installations there will necessarily have all Bugzilla features enabled,
13
and different installations run different versions, so some things may not
14
quite work as this document describes.</para>
17
<section id="myaccount">
18
<title>Create a Bugzilla Account</title>
20
<para>If you want to use Bugzilla, first you need to create an account.
21
Consult with the administrator responsible for your installation of
22
Bugzilla for the URL you should use to access it. If you're
23
test-driving Bugzilla, use this URL:
24
<ulink url="&landfillbase;"/>.
30
On the home page <filename>index.cgi</filename>, click the
31
<quote>Open a new Bugzilla account</quote> link, or the
32
<quote>New Account</quote> link available in the footer of pages.
33
Now enter your email address, then click the <quote>Send</quote>
39
If none of these links is available, this means that the
40
administrator of the installation has disabled self-registration.
41
This means that only an administrator can create accounts
42
for other users. One reason could be that this installation is
49
Also, if only some users are allowed to create an account on
50
the installation, you may see these links but your registration
51
may fail if your email address doesn't match the ones accepted
52
by the installation. This is another way to restrict who can
53
access and edit bugs in this installation.
60
Within moments, and if your registration is accepted, you should
61
receive an email to the address you provided, which contains your
62
login name (generally the same as the email address), and two URLs
63
with a token (a random string generated by the installation) to
64
confirm, respectively cancel, your registration. This is a way to
65
prevent users from abusing the generation of user accounts, for
66
instance by entering inexistent email addresses, or email addresses
67
which do not belong to them.
73
By default, you have 3 days to confirm your registration. Past this
74
timeframe, the token is invalidated and the registration is
75
automatically canceled. You can also cancel this registration sooner
76
by using the appropriate URL in the email you got.
82
If you confirm your registration, Bugzilla will ask you your real name
83
(optional, but recommended) and your password, which must be between
84
3 and 16 characters long.
90
Now all you need to do is to click the <quote>Log In</quote>
91
link in the footer at the bottom of the page in your browser,
92
enter your email address and password you just chose into the
93
login form, and click the <quote>Log in</quote> button.
99
You are now logged in. Bugzilla uses cookies to remember you are
100
logged in so, unless you have cookies disabled or your IP address changes,
101
you should not have to log in again during your session.
105
<section id="bug_page">
106
<title>Anatomy of a Bug</title>
108
<para>The core of Bugzilla is the screen which displays a particular
109
bug. It's a good place to explain some Bugzilla concepts.
111
url="&landfillbase;show_bug.cgi?id=1">
112
Bug 1 on Landfill</ulink>
114
is a good example. Note that the labels for most fields are hyperlinks;
115
clicking them will take you to context-sensitive help on that
116
particular field. Fields marked * may not be present on every
117
installation of Bugzilla.</para>
122
<emphasis>Product and Component</emphasis>:
123
Bugs are divided up by Product and Component, with a Product
124
having one or more Components in it. For example,
125
bugzilla.mozilla.org's "Bugzilla" Product is composed of several
129
<emphasis>Administration:</emphasis>
130
Administration of a Bugzilla installation.</member>
133
<emphasis>Bugzilla-General:</emphasis>
134
Anything that doesn't fit in the other components, or spans
135
multiple components.</member>
138
<emphasis>Creating/Changing Bugs:</emphasis>
139
Creating, changing, and viewing bugs.</member>
142
<emphasis>Documentation:</emphasis>
143
The Bugzilla documentation, including The Bugzilla Guide.</member>
146
<emphasis>Email:</emphasis>
147
Anything to do with email sent by Bugzilla.</member>
150
<emphasis>Installation:</emphasis>
151
The installation process of Bugzilla.</member>
154
<emphasis>Query/Buglist:</emphasis>
155
Anything to do with searching for bugs and viewing the
159
<emphasis>Reporting/Charting:</emphasis>
160
Getting reports from Bugzilla.</member>
163
<emphasis>User Accounts:</emphasis>
164
Anything about managing a user account from the user's perspective.
165
Saved queries, creating accounts, changing passwords, logging in,
169
<emphasis>User Interface:</emphasis>
170
General issues having to do with the user interface cosmetics (not
171
functionality) including cosmetic issues, HTML templates,
179
<emphasis>Status and Resolution:</emphasis>
181
These define exactly what state the bug is in - from not even
182
being confirmed as a bug, through to being fixed and the fix
183
confirmed by Quality Assurance. The different possible values for
184
Status and Resolution on your installation should be documented in the
185
context-sensitive help for those items.</para>
190
<emphasis>Assigned To:</emphasis>
191
The person responsible for fixing the bug.</para>
196
<emphasis>*QA Contact:</emphasis>
197
The person responsible for quality assurance on this bug.</para>
202
<emphasis>*URL:</emphasis>
203
A URL associated with the bug, if any.</para>
208
<emphasis>Summary:</emphasis>
209
A one-sentence summary of the problem.</para>
214
<emphasis>*Status Whiteboard:</emphasis>
215
(a.k.a. Whiteboard) A free-form text area for adding short notes
216
and tags to a bug.</para>
221
<emphasis>*Keywords:</emphasis>
222
The administrator can define keywords which you can use to tag and
223
categorise bugs - e.g. The Mozilla Project has keywords like crash
224
and regression.</para>
229
<emphasis>Platform and OS:</emphasis>
230
These indicate the computing environment where the bug was
236
<emphasis>Version:</emphasis>
237
The "Version" field is usually used for versions of a product which
238
have been released, and is set to indicate which versions of a
239
Component have the particular problem the bug report is
245
<emphasis>Priority:</emphasis>
246
The bug assignee uses this field to prioritize his or her bugs.
247
It's a good idea not to change this on other people's bugs.</para>
252
<emphasis>Severity:</emphasis>
253
This indicates how severe the problem is - from blocker
254
("application unusable") to trivial ("minor cosmetic issue"). You
255
can also use this field to indicate whether a bug is an enhancement
261
<emphasis>*Target:</emphasis>
262
(a.k.a. Target Milestone) A future version by which the bug is to
263
be fixed. e.g. The Bugzilla Project's milestones for future
264
Bugzilla versions are 2.18, 2.20, 3.0, etc. Milestones are not
265
restricted to numbers, thought - you can use any text strings, such
271
<emphasis>Reporter:</emphasis>
272
The person who filed the bug.</para>
277
<emphasis>CC list:</emphasis>
278
A list of people who get mail when the bug changes.</para>
283
<emphasis>*Time Tracking:</emphasis>
284
This form can be used for time tracking.
285
To use this feature, you have to be blessed group membership
286
specified by the <quote>timetrackinggroup</quote> parameter.
289
<emphasis>Orig. Est.:</emphasis>
290
This field shows the original estimated time.</member>
293
<emphasis>Current Est.:</emphasis>
294
This field shows the current estimated time.
295
This number is calculated from <quote>Hours Worked</quote>
296
and <quote>Hours Left</quote>.</member>
299
<emphasis>Hours Worked:</emphasis>
300
This field shows the number of hours worked.</member>
303
<emphasis>Hours Left:</emphasis>
304
This field shows the <quote>Current Est.</quote> -
305
<quote>Hours Worked</quote>.
306
This value + <quote>Hours Worked</quote> will become the
307
new Current Est.</member>
310
<emphasis>%Complete:</emphasis>
311
This field shows what percentage of the task is complete.</member>
314
<emphasis>Gain:</emphasis>
315
This field shows the number of hours that the bug is ahead of the
316
<quote>Orig. Est.</quote>.</member>
319
<emphasis>Deadline:</emphasis>
320
This field shows the deadline for this bug.</member>
327
<emphasis>Attachments:</emphasis>
328
You can attach files (e.g. testcases or patches) to bugs. If there
329
are any attachments, they are listed in this section. Attachments are
330
normally stored in the Bugzilla database, unless they are marked as
331
Big Files, which are stored directly on disk.
337
<emphasis>*Dependencies:</emphasis>
338
If this bug cannot be fixed unless other bugs are fixed (depends
339
on), or this bug stops other bugs being fixed (blocks), their
340
numbers are recorded here.</para>
345
<emphasis>*Votes:</emphasis>
346
Whether this bug has any votes.</para>
351
<emphasis>Additional Comments:</emphasis>
352
You can add your two cents to the bug discussion here, if you have
353
something worthwhile to say.</para>
358
<section id="lifecycle">
359
<title>Life Cycle of a Bug</title>
362
The life cycle, also known as work flow, of a bug is currently hardcoded
363
into Bugzilla. <xref linkend="lifecycle-image"/> contains a graphical
364
representation of this life cycle. If you wish to customize this image for
365
your site, the <ulink url="../images/bzLifecycle.xml">diagram file</ulink>
366
is available in <ulink url="http://www.gnome.org/projects/dia">Dia's</ulink>
370
<figure id="lifecycle-image">
371
<title>Lifecycle of a Bugzilla Bug</title>
374
<imagedata fileref="../images/bzLifecycle.png" scale="66" />
381
<title>Searching for Bugs</title>
383
<para>The Bugzilla Search page is the interface where you can find
384
any bug report, comment, or patch currently in the Bugzilla system. You
385
can play with it here:
386
<ulink url="&landfillbase;query.cgi"/>.</para>
388
<para>The Search page has controls for selecting different possible
389
values for all of the fields in a bug, as described above. For some
390
fields, multiple values can be selected. In those cases, Bugzilla
391
returns bugs where the content of the field matches any one of the selected
392
values. If none is selected, then the field can take any value.</para>
395
Once you've run a search, you can save it as a Saved Search, which
396
appears in the page footer.
397
On the Saved Searches tab of your User Preferences page (the Prefs link
398
in Bugzilla's footer), members of the group defined in the
399
querysharegroup parameter can share such Saved Searches with user groups
400
so that other users may use them.
401
At the same place, you can see Saved Searches other users are sharing, and
402
have them show up in your personal Bugzilla footer along with your own
404
If somebody is sharing a Search with a group she or he is allowed to
405
<link linkend="groups">assign users to</link>, the sharer may opt to have
406
the Search show up in the group's direct members' footers by default.
409
<section id="boolean">
410
<title>Boolean Charts</title>
412
Highly advanced querying is done using Boolean Charts.
415
The boolean charts further restrict the set of results
416
returned by a query. It is possible to search for bugs
417
based on elaborate combinations of criteria.
420
The simplest boolean searches have only one term. These searches
421
permit the selected left <emphasis>field</emphasis>
422
to be compared using a
423
selectable <emphasis>operator</emphasis> to a
424
specified <emphasis>value.</emphasis>
425
Using the "And," "Or," and "Add Another Boolean Chart" buttons,
426
additional terms can be included in the query, further
427
altering the list of bugs returned by the query.
430
There are three fields in each row of a boolean search.
435
<emphasis>Field:</emphasis>
436
the items being searched
441
<emphasis>Operator:</emphasis>
442
the comparison operator
447
<emphasis>Value:</emphasis>
448
the value to which the field is being compared
452
<section id="pronouns">
453
<title>Pronoun Substitution</title>
455
Sometimes, a query needs to compare a user-related field
456
(such as ReportedBy) with a role-specific user (such as the
457
user running the query or the user to whom each bug is assigned).
458
When the operator is either "equals" or "notequals", the value
459
can be "%reporter%", "%assignee%", "%qacontact%", or "%user%".
461
refers to the user who is executing the query or, in the case
462
of whining reports, the user who will be the recipient
463
of the report. The reporter, assignee, and qacontact
464
pronouns refer to the corresponding fields in the bug.
467
Boolean charts also let you type a group name in any user-related
468
field if the operator is either "equals", "notequals" or "anyexact".
469
This will let you query for any member belonging (or not) to the
470
specified group. The group name must be entered following the
471
"%group.foo%" syntax, where "foo" is the group name.
472
So if you are looking for bugs reported by any user being in the
473
"editbugs" group, then you can type "%group.editbugs%".
476
<section id="negation">
477
<title>Negation</title>
479
At first glance, negation seems redundant. Rather than
483
NOT("summary" "contains the string" "foo"),
489
("summary" "does not contain the string" "foo").
495
("CC" "does not contain the string" "@mozilla.org")
498
would find every bug where anyone on the CC list did not contain
502
NOT("CC" "contains the string" "@mozilla.org")
505
would find every bug where there was nobody on the CC list who
506
did contain the string. Similarly, the use of negation also permits
507
complex expressions to be built using terms OR'd together and then
508
negated. Negation permits queries such as
511
NOT(("product" "equals" "update") OR
512
("component" "equals" "Documentation"))
515
to find bugs that are neither
516
in the update product or in the documentation component or
519
NOT(("commenter" "equals" "%assignee%") OR
520
("component" "equals" "Documentation"))
523
to find non-documentation
524
bugs on which the assignee has never commented.
527
<section id="multiplecharts">
528
<title>Multiple Charts</title>
530
The terms within a single row of a boolean chart are all
531
constraints on a single piece of data. If you are looking for
532
a bug that has two different people cc'd on it, then you need
533
to use two boolean charts. A search for
536
("cc" "contains the string" "foo@") AND
537
("cc" "contains the string" "@mozilla.org")
540
would return only bugs with "foo@mozilla.org" on the cc list.
541
If you wanted bugs where there is someone on the cc list
542
containing "foo@" and someone else containing "@mozilla.org",
543
then you would need two boolean charts.
546
First chart: ("cc" "contains the string" "foo@")
549
Second chart: ("cc" "contains the string" "@mozilla.org")
552
The bugs listed will be only the bugs where ALL the charts are true.
557
<section id="quicksearch">
558
<title>Quicksearch</title>
561
Quicksearch is a single-text-box query tool which uses
562
metacharacters to indicate what is to be searched. For example, typing
563
"<literal>foo|bar</literal>"
564
into Quicksearch would search for "foo" or "bar" in the
565
summary and status whiteboard of a bug; adding
566
"<literal>:BazProduct</literal>" would
567
search only in that product.
568
You can use it to find a bug by its number or its alias, too.
572
You'll find the Quicksearch box in Bugzilla's footer area.
573
On Bugzilla's front page, there is an additional
574
<ulink url="../../page.cgi?id=quicksearch.html">Help</ulink>
575
link which details how to use it.
579
<section id="casesensitivity">
580
<title>Case Sensitivity in Searches</title>
582
Bugzilla queries are case-insensitive and accent-insensitive, when
583
used with MySQL databases. When using Bugzilla with
584
PostgreSQL, however, some queries are case-sensitive. This is due to
585
the way PostgreSQL handles case and accent sensitivity.
590
<title>Bug Lists</title>
592
<para>If you run a search, a list of matching bugs will be returned.
595
<para>The format of the list is configurable. For example, it can be
596
sorted by clicking the column headings. Other useful features can be
597
accessed using the links at the bottom of the list:
600
<emphasis>Long Format:</emphasis>
602
this gives you a large page with a non-editable summary of the fields
603
of each bug.</member>
606
<emphasis>XML:</emphasis>
608
get the buglist in the XML format.</member>
611
<emphasis>CSV:</emphasis>
613
get the buglist as comma-separated values, for import into e.g.
614
a spreadsheet.</member>
617
<emphasis>Feed:</emphasis>
619
get the buglist as an Atom feed. Copy this link into your
620
favorite feed reader. If you are using Firefox, you can also
621
save the list as a live bookmark by clicking the live bookmark
622
icon in the status bar. To limit the number of bugs in the feed,
623
add a limit=n parameter to the URL.</member>
626
<emphasis>iCalendar:</emphasis>
628
Get the buglist as an iCalendar file. Each bug is represented as a
629
to-do item in the imported calendar.</member>
632
<emphasis>Change Columns:</emphasis>
634
change the bug attributes which appear in the list.</member>
637
<emphasis>Change several bugs at once:</emphasis>
639
If your account is sufficiently empowered, and more than one bug
640
appear in the bug list, this link is displayed which lets you make
641
the same change to all the bugs in the list - for example, changing
642
their assignee.</member>
645
<emphasis>Send mail to bug assignees:</emphasis>
647
If more than one bug appear in the bug list and there are at least
648
two distinct bug assignees, this links is displayed which lets you
649
easily send a mail to the assignees of all bugs on the list.</member>
652
<emphasis>Edit Search:</emphasis>
654
If you didn't get exactly the results you were looking for, you can
655
return to the Query page through this link and make small revisions
656
to the query you just made so you get more accurate results.</member>
659
<emphasis>Remember Search As:</emphasis>
661
You can give a search a name and remember it; a link will appear
662
in your page footer giving you quick access to run it again later.
668
If you would like to access the bug list from another program
669
it is often useful to have the list returned in something other
670
than HTML. By adding the ctype=type parameter into the bug list URL
671
you can specify several alternate formats. Besides the types described
672
above, the following formats are also supported: ECMAScript, also known
673
as JavaScript (ctype=js), and Resource Description Framework RDF/XML
678
<section id="individual-buglists">
679
<title>Adding/removing tags to/from bugs</title>
681
You can add and remove tags from individual bugs, which let you find and
682
manage them more easily. Creating a new tag automatically generates a saved
683
search - whose name is the name of the tag - which lists bugs with this tag.
684
This saved search will be displayed in the footer of pages by default, as
685
all other saved searches. The main difference between tags and normal saved
686
searches is that saved searches, as described in the previous section, are
687
stored in the form of a list of matching criteria, while the saved search
688
generated by tags is a list of bug numbers. Consequently, you can easily
689
edit this list by either adding or removing tags from bugs. To enable this
690
feature, you have to turn on the <quote>Enable tags for bugs</quote> user
691
preference, see <xref linkend="userpreferences" />. This feature is disabled
696
This feature is useful when you want to keep track of several bugs, but
697
for different reasons. Instead of adding yourself to the CC list of all
698
these bugs and mixing all these reasons, you can now store these bugs in
699
separate lists, e.g. <quote>Keep in mind</quote>, <quote>Interesting bugs</quote>,
700
or <quote>Triage</quote>. One big advantage of this way to manage bugs
701
is that you can easily add or remove bugs one by one, which is not
702
possible to do with saved searches without having to edit the search
708
<section id="bugreports">
709
<title>Filing Bugs</title>
711
<section id="fillingbugs">
712
<title>Reporting a New Bug</title>
714
<para>Years of bug writing experience has been distilled for your
715
reading pleasure into the
717
url="&landfillbase;page.cgi?id=bug-writing.html">
718
Bug Writing Guidelines</ulink>.
719
While some of the advice is Mozilla-specific, the basic principles of
720
reporting Reproducible, Specific bugs, isolating the Product you are
721
using, the Version of the Product, the Component which failed, the
722
Hardware Platform, and Operating System you were using at the time of
723
the failure go a long way toward ensuring accurate, responsible fixes
724
for the bug that bit you.</para>
726
<para>The procedure for filing a bug is as follows:</para>
731
Click the <quote>New</quote> link available in the footer
732
of pages, or the <quote>Enter a new bug report</quote> link
733
displayed on the home page of the Bugzilla installation.
738
If you want to file a test bug to see how Bugzilla works,
739
you can do it on one of our test installations on
740
<ulink url="&landfillbase;">Landfill</ulink>.
747
You first have to select the product in which you found a bug.
753
You now see a form where you can specify the component (part of
754
the product which is affected by the bug you discovered; if you have
755
no idea, just select <quote>General</quote> if such a component exists),
756
the version of the program you were using, the Operating System and
757
platform your program is running on and the severity of the bug (if the
758
bug you found crashes the program, it's probably a major or a critical
759
bug; if it's a typo somewhere, that's something pretty minor; if it's
760
something you would like to see implemented, then that's an enhancement).
766
You now have to give a short but descriptive summary of the bug you found.
767
<quote>My program is crashing all the time</quote> is a very poor summary
768
and doesn't help developers at all. Try something more meaningful or
769
your bug will probably be ignored due to a lack of precision.
770
The next step is to give a very detailed list of steps to reproduce
771
the problem you encountered. Try to limit these steps to a minimum set
772
required to reproduce the problem. This will make the life of
773
developers easier, and the probability that they consider your bug in
774
a reasonable timeframe will be much higher.
779
Try to make sure that everything in the summary is also in the first
780
comment. Summaries are often updated and this will ensure your original
781
information is easily accessible.
788
As you file the bug, you can also attach a document (testcase, patch,
789
or screenshot of the problem).
795
Depending on the Bugzilla installation you are using and the product in
796
which you are filing the bug, you can also request developers to consider
797
your bug in different ways (such as requesting review for the patch you
798
just attached, requesting your bug to block the next release of the
799
product, and many other product specific requests).
805
Now is a good time to read your bug report again. Remove all misspellings,
806
otherwise your bug may not be found by developers running queries for some
807
specific words, and so your bug would not get any attention.
808
Also make sure you didn't forget any important information developers
809
should know in order to reproduce the problem, and make sure your
810
description of the problem is explicit and clear enough.
811
When you think your bug report is ready to go, the last step is to
812
click the <quote>Commit</quote> button to add your report into the database.
818
You do not need to put "any" or similar strings in the URL field.
819
If there is no specific URL associated with the bug, leave this
823
<para>If you feel a bug you filed was incorrectly marked as a
824
DUPLICATE of another, please question it in your bug, not
825
the bug it was duped to. Feel free to CC the person who duped it
826
if they are not already CCed.
830
<section id="cloningbugs">
831
<title>Clone an Existing Bug</title>
834
Starting with version 2.20, Bugzilla has a feature that allows you
835
to clone an existing bug. The newly created bug will inherit
836
most settings from the old bug. This allows you to track more
837
easily similar concerns in a new bug. To use this, go to the bug
838
that you want to clone, then click the <quote>Clone This Bug</quote>
839
link on the bug page. This will take you to the <quote>Enter Bug</quote>
840
page that is filled with the values that the old bug has.
841
You can change those values and/or texts if needed.
847
<section id="attachments">
848
<title>Attachments</title>
851
You should use attachments, rather than comments, for large chunks of ASCII
852
data, such as trace, debugging output files, or log files. That way, it
853
doesn't bloat the bug for everyone who wants to read it, and cause people to
854
receive fat, useless mails.
857
<para>You should make sure to trim screenshots. There's no need to show the
858
whole screen if you are pointing out a single-pixel problem.
861
<para>Bugzilla stores and uses a Content-Type for each attachment
862
(e.g. text/html). To download an attachment as a different
863
Content-Type (e.g. application/xhtml+xml), you can override this
864
using a 'content_type' parameter on the URL, e.g.
865
<filename>&content_type=text/plain</filename>.
869
If you have a really large attachment, something that does not need to
870
be recorded forever (as most attachments are), or something that is too
871
big for your database, you can mark your attachment as a
872
<quote>Big File</quote>, assuming the administrator of the installation
873
has enabled this feature. Big Files are stored directly on disk instead
874
of in the database. The maximum size of a <quote>Big File</quote> is
875
normally larger than the maximum size of a regular attachment. Independently
876
of the storage system used, an administrator can delete these attachments
877
at any time. Nevertheless, if these files are stored in the database, the
878
<quote>allow_attachment_deletion</quote> parameter (which is turned off
879
by default) must be enabled in order to delete them.
883
Also, if the administrator turned on the <quote>allow_attach_url</quote>
884
parameter, you can enter the URL pointing to the attachment instead of
885
uploading the attachment itself. For example, this is useful if you want to
886
point to an external application, a website or a very large file. Note that
887
there is no guarantee that the source file will always be available, nor
888
that its content will remain unchanged.
891
<section id="patchviewer">
892
<title>Patch Viewer</title>
894
<para>Viewing and reviewing patches in Bugzilla is often difficult due to
895
lack of context, improper format and the inherent readability issues that
896
raw patches present. Patch Viewer is an enhancement to Bugzilla designed
897
to fix that by offering increased context, linking to sections, and
898
integrating with Bonsai, LXR and CVS.</para>
900
<para>Patch viewer allows you to:</para>
903
<member>View patches in color, with side-by-side view rather than trying
904
to interpret the contents of the patch.</member>
905
<member>See the difference between two patches.</member>
906
<member>Get more context in a patch.</member>
907
<member>Collapse and expand sections of a patch for easy
909
<member>Link to a particular section of a patch for discussion or
911
<member>Go to Bonsai or LXR to see more context, blame, and
912
cross-references for the part of the patch you are looking at</member>
913
<member>Create a rawtext unified format diff out of any patch, no
914
matter what format it came from</member>
917
<section id="patchviewer_view">
918
<title>Viewing Patches in Patch Viewer</title>
919
<para>The main way to view a patch in patch viewer is to click on the
920
"Diff" link next to a patch in the Attachments list on a bug. You may
921
also do this within the edit window by clicking the "View Attachment As
922
Diff" button in the Edit Attachment screen.</para>
925
<section id="patchviewer_diff">
926
<title>Seeing the Difference Between Two Patches</title>
927
<para>To see the difference between two patches, you must first view the
928
newer patch in Patch Viewer. Then select the older patch from the
929
dropdown at the top of the page ("Differences between [dropdown] and
930
this patch") and click the "Diff" button. This will show you what
931
is new or changed in the newer patch.</para>
934
<section id="patchviewer_context">
935
<title>Getting More Context in a Patch</title>
936
<para>To get more context in a patch, you put a number in the textbox at
937
the top of Patch Viewer ("Patch / File / [textbox]") and hit enter.
938
This will give you that many lines of context before and after each
939
change. Alternatively, you can click on the "File" link there and it
940
will show each change in the full context of the file. This feature only
941
works against files that were diffed using "cvs diff".</para>
944
<section id="patchviewer_collapse">
945
<title>Collapsing and Expanding Sections of a Patch</title>
946
<para>To view only a certain set of files in a patch (for example, if a
947
patch is absolutely huge and you want to only review part of it at a
948
time), you can click the "(+)" and "(-)" links next to each file (to
949
expand it or collapse it). If you want to collapse all files or expand
950
all files, you can click the "Collapse All" and "Expand All" links at the
951
top of the page.</para>
954
<section id="patchviewer_link">
955
<title>Linking to a Section of a Patch</title>
956
<para>To link to a section of a patch (for example, if you want to be
957
able to give someone a URL to show them which part you are talking
958
about) you simply click the "Link Here" link on the section header. The
959
resulting URL can be copied and used in discussion.</para>
962
<section id="patchviewer_bonsai_lxr">
963
<title>Going to Bonsai and LXR</title>
964
<para>To go to Bonsai to get blame for the lines you are interested in,
965
you can click the "Lines XX-YY" link on the section header you are
966
interested in. This works even if the patch is against an old
967
version of the file, since Bonsai stores all versions of the file.</para>
969
<para>To go to LXR, you click on the filename on the file header
970
(unfortunately, since LXR only does the most recent version, line
971
numbers are likely to rot).</para>
974
<section id="patchviewer_unified_diff">
975
<title>Creating a Unified Diff</title>
976
<para>If the patch is not in a format that you like, you can turn it
977
into a unified diff format by clicking the "Raw Unified" link at the top
983
<section id="hintsandtips">
984
<title>Hints and Tips</title>
986
<para>This section distills some Bugzilla tips and best practices
987
that have been developed.</para>
990
<title>Autolinkification</title>
991
<para>Bugzilla comments are plain text - so typing <U> will
992
produce less-than, U, greater-than rather than underlined text.
993
However, Bugzilla will automatically make hyperlinks out of certain
994
sorts of text in comments. For example, the text
995
"http://www.bugzilla.org" will be turned into a link:
996
<ulink url="http://www.bugzilla.org"/>.
997
Other strings which get linkified in the obvious manner are:
999
<member>bug 12345</member>
1000
<member>comment 7</member>
1001
<member>bug 23456, comment 53</member>
1002
<member>attachment 4321</member>
1003
<member>mailto:george@example.com</member>
1004
<member>george@example.com</member>
1005
<member>ftp://ftp.mozilla.org</member>
1006
<member>Most other sorts of URL</member>
1010
<para>A corollary here is that if you type a bug number in a comment,
1011
you should put the word "bug" before it, so it gets autolinkified
1012
for the convenience of others.
1016
<section id="commenting">
1017
<title>Comments</title>
1019
<para>If you are changing the fields on a bug, only comment if
1020
either you have something pertinent to say, or Bugzilla requires it.
1021
Otherwise, you may spam people unnecessarily with bug mail.
1022
To take an example: a user can set up their account to filter out messages
1023
where someone just adds themselves to the CC field of a bug
1024
(which happens a lot.) If you come along, add yourself to the CC field,
1025
and add a comment saying "Adding self to CC", then that person
1026
gets a pointless piece of mail they would otherwise have avoided.
1030
Don't use sigs in comments. Signing your name ("Bill") is acceptable,
1031
if you do it out of habit, but full mail/news-style
1032
four line ASCII art creations are not.
1036
<section id="comment-wrapping">
1037
<title>Server-Side Comment Wrapping</title>
1039
Bugzilla stores comments unwrapped and wraps them at display time. This
1040
ensures proper wrapping in all browsers. Lines beginning with the ">"
1041
character are assumed to be quotes, and are not wrapped.
1045
<section id="dependencytree">
1046
<title>Dependency Tree</title>
1049
On the <quote>Dependency tree</quote> page linked from each bug
1050
page, you can see the dependency relationship from the bug as a
1055
You can change how much depth to show, and you can hide resolved bugs
1056
from this page. You can also collaps/expand dependencies for
1057
each bug on the tree view, using the [-]/[+] buttons that appear
1058
before its summary. This option is not available for terminal
1059
bugs in the tree (that don't have further dependencies).
1064
<section id="timetracking">
1065
<title>Time Tracking Information</title>
1068
Users who belong to the group specified by the <quote>timetrackinggroup</quote>
1069
parameter have access to time-related fields. Developers can see
1070
deadlines and estimated times to fix bugs, and can provide time spent
1075
At any time, a summary of the time spent by developers on bugs is
1076
accessible either from bug lists when clicking the <quote>Time Summary</quote>
1077
button or from individual bugs when clicking the <quote>Summarize time</quote>
1078
link in the time tracking table. The <filename>summarize_time.cgi</filename>
1079
page lets you view this information either per developer or per bug,
1080
and can be split on a month basis to have greater details on how time
1081
is spent by developers.
1085
As soon as a bug is marked as RESOLVED, the remaining time expected
1086
to fix the bug is set to zero. This lets QA people set it again for
1087
their own usage, and it will be set to zero again when the bug will
1088
be marked as CLOSED.
1092
<section id="userpreferences">
1093
<title>User Preferences</title>
1096
Once logged in, you can customize various aspects of
1097
Bugzilla via the "Preferences" link in the page footer.
1098
The preferences are split into five tabs:</para>
1100
<section id="generalpreferences" xreflabel="General Preferences">
1101
<title>General Preferences</title>
1104
This tab allows you to change several default settings of Bugzilla.
1107
<itemizedlist spacing="compact">
1110
Bugzilla's general appearance (skin) - select which skin to use.
1111
Bugzilla supports adding custom skins.
1116
Field separator character for CSV files -
1117
Select between a comma and semi-colon for exported CSV bug lists.
1122
Automatically add me to the CC list of bugs I change - set default
1123
behavior of CC list. Options include "Always", "Never", and "Only
1124
if I have no role on them".
1129
Language used in email - select which language email will be sent in,
1130
from the list of available languages.
1135
After changing a bug - This controls what page is displayed after
1136
changes to a bug are submitted. The options include to show the bug
1137
just modified, to show the next bug in your list, or to do nothing.
1142
Enable tags for bugs - turn bug tagging on or off.
1147
When viewing a bug, show comments in this order -
1148
controls the order of comments. Options include "Oldest
1149
to Newest", "Newest to Oldest" and "Newest to Oldest, but keep the
1150
bug description at the top".
1155
Show a quip at the top of each bug list - controls
1156
whether a quip will be shown on the Bug list page.
1161
Zoom textareas large when in use (requires JavaScript) - enable or
1162
disable the automatic expanding of text areas when text is being
1169
<section id="emailpreferences">
1170
<title>Email Preferences</title>
1173
This tab allows you to enable or disable email notification on
1178
In general, users have almost complete control over how much (or
1179
how little) email Bugzilla sends them. If you want to receive the
1180
maximum amount of email possible, click the <quote>Enable All
1181
Mail</quote> button. If you don't want to receive any email from
1182
Bugzilla at all, click the <quote>Disable All Mail</quote> button.
1187
A Bugzilla administrator can stop a user from receiving
1188
bugmail by clicking the <quote>Bugmail Disabled</quote> checkbox
1189
when editing the user account. This is a drastic step
1190
best taken only for disabled accounts, as it overrides
1191
the user's individual mail preferences.
1196
There are two global options -- <quote>Email me when someone
1197
asks me to set a flag</quote> and <quote>Email me when someone
1198
sets a flag I asked for</quote>. These define how you want to
1199
receive bugmail with regards to flags. Their use is quite
1200
straightforward; enable the checkboxes if you want Bugzilla to
1201
send you mail under either of the above conditions.
1205
If you'd like to set your bugmail to something besides
1206
'Completely ON' and 'Completely OFF', the
1207
<quote>Field/recipient specific options</quote> table
1208
allows you to do just that. The rows of the table
1209
define events that can happen to a bug -- things like
1210
attachments being added, new comments being made, the
1211
priority changing, etc. The columns in the table define
1212
your relationship with the bug:
1215
<itemizedlist spacing="compact">
1218
Reporter - Where you are the person who initially
1219
reported the bug. Your name/account appears in the
1220
<quote>Reporter:</quote> field.
1225
Assignee - Where you are the person who has been
1226
designated as the one responsible for the bug. Your
1227
name/account appears in the <quote>Assigned To:</quote>
1233
QA Contact - You are one of the designated
1234
QA Contacts for the bug. Your account appears in the
1235
<quote>QA Contact:</quote> text-box of the bug.
1240
CC - You are on the list CC List for the bug.
1241
Your account appears in the <quote>CC:</quote> text box
1247
Voter - You have placed one or more votes for the bug.
1248
Your account appears only if someone clicks on the
1249
<quote>Show votes for this bug</quote> link on the bug.
1256
Some columns may not be visible for your installation, depending
1257
on your site's configuration.
1262
To fine-tune your bugmail, decide the events for which you want
1263
to receive bugmail; then decide if you want to receive it all
1264
the time (enable the checkbox for every column), or only when
1265
you have a certain relationship with a bug (enable the checkbox
1266
only for those columns). For example: if you didn't want to
1267
receive mail when someone added themselves to the CC list, you
1268
could uncheck all the boxes in the <quote>CC Field Changes</quote>
1269
line. As another example, if you never wanted to receive email
1270
on bugs you reported unless the bug was resolved, you would
1271
un-check all boxes in the <quote>Reporter</quote> column
1272
except for the one on the <quote>The bug is resolved or
1273
verified</quote> row.
1278
Bugzilla adds the <quote>X-Bugzilla-Reason</quote> header to
1279
all bugmail it sends, describing the recipient's relationship
1280
(AssignedTo, Reporter, QAContact, CC, or Voter) to the bug.
1281
This header can be used to do further client-side filtering.
1286
Bugzilla has a feature called <quote>Users Watching</quote>.
1287
When you enter one or more comma-delineated user accounts (usually email
1288
addresses) into the text entry box, you will receive a copy of all the
1289
bugmail those users are sent (security settings permitting).
1290
This powerful functionality enables seamless transitions as developers
1291
change projects or users go on holiday.
1296
The ability to watch other users may not be available in all
1297
Bugzilla installations. If you don't see this feature, and feel
1298
that you need it, speak to your administrator.
1303
Each user listed in the <quote>Users watching you</quote> field
1304
has you listed in their <quote>Users to watch</quote> list
1305
and can get bugmail according to your relationship to the bug and
1306
their <quote>Field/recipient specific options</quote> setting.
1311
<section id="savedsearches" xreflabel="Saved Searches">
1312
<title>Saved Searches</title>
1314
On this tab you can view and run any Saved Searches that you have
1315
created, and also any Saved Searches that other members of the group
1316
defined in the "querysharegroup" parameter have shared.
1317
Saved Searches can be added to the page footer from this screen.
1318
If somebody is sharing a Search with a group she or he is allowed to
1319
<link linkend="groups">assign users to</link>, the sharer may opt to have
1320
the Search show up in the footer of the group's direct members by default.
1324
<section id="accountpreferences" xreflabel="Name and Password">
1325
<title>Name and Password</title>
1327
<para>On this tab, you can change your basic account information,
1328
including your password, email address and real name. For security
1329
reasons, in order to change anything on this page you must type your
1330
<emphasis>current</emphasis> password into the <quote>Password</quote>
1331
field at the top of the page.
1332
If you attempt to change your email address, a confirmation
1333
email is sent to both the old and new addresses, with a link to use to
1334
confirm the change. This helps to prevent account hijacking.</para>
1337
<section id="permissionsettings">
1338
<title>Permissions</title>
1341
This is a purely informative page which outlines your current
1342
permissions on this installation of Bugzilla.
1346
A complete list of permissions is below. Only users with
1347
<emphasis>editusers</emphasis> privileges can change the permissions
1358
Indicates user is an Administrator.
1365
bz_canusewhineatothers
1369
Indicates user can configure whine reports for other users.
1380
Indicates user can configure whine reports for self.
1391
Indicates user can perform actions as other users.
1402
Indicates user can not be impersonated by other users.
1413
Indicates user can confirm a bug or mark it a duplicate.
1424
Indicates user can create and destroy groups.
1435
Indicates user can edit all bug fields.
1446
Indicates user can create, destroy, and edit classifications.
1457
Indicates user can create, destroy, and edit components.
1468
Indicates user can create, destroy, and edit keywords.
1479
Indicates user can edit or disable users.
1490
Indicates user can change Parameters.
1499
For more information on how permissions work in Bugzilla (i.e. who can
1500
change what), see <xref linkend="cust-change-permissions"/>.
1508
<section id="reporting">
1509
<title>Reports and Charts</title>
1511
<para>As well as the standard buglist, Bugzilla has two more ways of
1512
viewing sets of bugs. These are the reports (which give different
1513
views of the current state of the database) and charts (which plot
1514
the changes in particular sets of bugs over time.)</para>
1516
<section id="reports">
1517
<title>Reports</title>
1520
A report is a view of the current state of the bug database.
1524
You can run either an HTML-table-based report, or a graphical
1525
line/pie/bar-chart-based one. The two have different pages to
1526
define them, but are close cousins - once you've defined and
1527
viewed a report, you can switch between any of the different
1528
views of the data at will.
1532
Both report types are based on the idea of defining a set of bugs
1533
using the standard search interface, and then choosing some
1534
aspect of that set to plot on the horizontal and/or vertical axes.
1535
You can also get a form of 3-dimensional report by choosing to have
1536
multiple images or tables.
1540
So, for example, you could use the search form to choose "all
1541
bugs in the WorldControl product", and then plot their severity
1542
against their component to see which component had had the largest
1543
number of bad bugs reported against it.
1547
Once you've defined your parameters and hit "Generate Report",
1548
you can switch between HTML, CSV, Bar, Line and Pie. (Note: Pie
1549
is only available if you didn't define a vertical axis, as pie
1550
charts don't have one.) The other controls are fairly self-explanatory;
1551
you can change the size of the image if you find text is overwriting
1552
other text, or the bars are too thin to see.
1557
<section id="charts">
1558
<title>Charts</title>
1561
A chart is a view of the state of the bug database over time.
1565
Bugzilla currently has two charting systems - Old Charts and New
1566
Charts. Old Charts have been part of Bugzilla for a long time; they
1567
chart each status and resolution for each product, and that's all.
1568
They are deprecated, and going away soon - we won't say any more
1570
New Charts are the future - they allow you to chart anything you
1571
can define as a search.
1576
Both charting forms require the administrator to set up the
1577
data-gathering script. If you can't see any charts, ask them whether
1583
An individual line on a chart is called a data set.
1584
All data sets are organised into categories and subcategories. The
1585
data sets that Bugzilla defines automatically use the Product name
1586
as a Category and Component names as Subcategories, but there is no
1587
need for you to follow that naming scheme with your own charts if
1592
Data sets may be public or private. Everyone sees public data sets in
1593
the list, but only their creator sees private data sets. Only
1594
administrators can make data sets public.
1595
No two data sets, even two private ones, can have the same set of
1596
category, subcategory and name. So if you are creating private data
1597
sets, one idea is to have the Category be your username.
1601
<title>Creating Charts</title>
1604
You create a chart by selecting a number of data sets from the
1605
list, and pressing Add To List for each. In the List Of Data Sets
1606
To Plot, you can define the label that data set will have in the
1607
chart's legend, and also ask Bugzilla to Sum a number of data sets
1608
(e.g. you could Sum data sets representing RESOLVED, VERIFIED and
1609
CLOSED in a particular product to get a data set representing all
1610
the resolved bugs in that product.)
1614
If you've erroneously added a data set to the list, select it
1615
using the checkbox and click Remove. Once you add more than one
1616
data set, a "Grand Total" line
1617
automatically appears at the bottom of the list. If you don't want
1618
this, simply remove it as you would remove any other line.
1622
You may also choose to plot only over a certain date range, and
1623
to cumulate the results - that is, to plot each one using the
1624
previous one as a baseline, so the top line gives a sum of all
1625
the data sets. It's easier to try than to explain :-)
1629
Once a data set is in the list, one can also perform certain
1630
actions on it. For example, one can edit the
1631
data set's parameters (name, frequency etc.) if it's one you
1632
created or if you are an administrator.
1636
Once you are happy, click Chart This List to see the chart.
1642
<title>Creating New Data Sets</title>
1645
You may also create new data sets of your own. To do this,
1646
click the "create a new data set" link on the Create Chart page.
1647
This takes you to a search-like interface where you can define
1648
the search that Bugzilla will plot. At the bottom of the page,
1649
you choose the category, sub-category and name of your new
1654
If you have sufficient permissions, you can make the data set public,
1655
and reduce the frequency of data collection to less than the default
1664
<section id="flags">
1665
<title>Flags</title>
1668
A flag is a kind of status that can be set on bugs or attachments
1669
to indicate that the bugs/attachments are in a certain state.
1670
Each installation can define its own set of flags that can be set
1671
on bugs or attachments.
1675
If your installation has defined a flag, you can set or unset that flag,
1676
and if your administrator has enabled requesting of flags, you can submit
1677
a request for another user to set the flag.
1681
To set a flag, select either "+" or "-" from the drop-down menu next to
1682
the name of the flag in the "Flags" list. The meaning of these values are
1683
flag-specific and thus cannot be described in this documentation,
1684
but by way of example, setting a flag named "review" to "+" may indicate
1685
that the bug/attachment has passed review, while setting it to "-"
1686
may indicate that the bug/attachment has failed review.
1690
To unset a flag, click its drop-down menu and select the blank value.
1691
Note that marking an attachment as obsolete automatically cancels all
1692
pending requests for the attachment.
1696
If your administrator has enabled requests for a flag, request a flag
1697
by selecting "?" from the drop-down menu and then entering the username
1698
of the user you want to set the flag in the text field next to the menu.
1702
A set flag appears in bug reports and on "edit attachment" pages with the
1703
abbreviated username of the user who set the flag prepended to the
1704
flag name. For example, if Jack sets a "review" flag to "+", it appears
1705
as Jack: review [ + ]
1709
A requested flag appears with the user who requested the flag prepended
1710
to the flag name and the user who has been requested to set the flag
1711
appended to the flag name within parentheses. For example, if Jack
1712
asks Jill for review, it appears as Jack: review [ ? ] (Jill).
1716
You can browse through open requests made of you and by you by selecting
1717
'My Requests' from the footer. You can also look at open requests limited
1718
by other requesters, requestees, products, components, and flag names from
1719
this page. Note that you can use '-' for requestee to specify flags with
1724
<section id="whining">
1725
<title>Whining</title>
1728
Whining is a feature in Bugzilla that can regularly annoy users at
1729
specified times. Using this feature, users can execute saved searches
1730
at specific times (i.e. the 15th of the month at midnight) or at
1731
regular intervals (i.e. every 15 minutes on Sundays). The results of the
1732
searches are sent to the user, either as a single email or as one email
1733
per bug, along with some descriptive text.
1738
Throughout this section it will be assumed that all users are members
1739
of the bz_canusewhines group, membership in which is required in order
1740
to use the Whining system. You can easily make all users members of
1741
the bz_canusewhines group by setting the User RegExp to ".*" (without
1746
Also worth noting is the bz_canusewhineatothers group. Members of this
1747
group can create whines for any user or group in Bugzilla using a
1748
extended form of the whining interface. Features only available to
1749
members of the bz_canusewhineatothers group will be noted in the
1756
For whining to work, a special Perl script must be executed at regular
1757
intervals. More information on this is available in
1758
<xref linkend="installation-whining"/>.
1764
This section does not cover the whineatnews.pl script. See
1765
<xref linkend="installation-whining-cron"/> for more information on
1770
<section id="whining-overview">
1771
<title>The Event</title>
1774
The whining system defines an "Event" as one or more queries being
1775
executed at regular intervals, with the results of said queries (if
1776
there are any) being emailed to the user. Events are created by
1777
clicking on the "Add new event" button.
1781
Once a new event is created, the first thing to set is the "Email
1782
subject line". The contents of this field will be used in the subject
1783
line of every email generated by this event. In addition to setting a
1784
subject, space is provided to enter some descriptive text that will be
1785
included at the top of each message (to help you in understanding why
1786
you received the email in the first place).
1790
The next step is to specify when the Event is to be run (the Schedule)
1791
and what searches are to be performed (the Searches).
1796
<section id="whining-schedule">
1797
<title>Whining Schedule</title>
1800
Each whining event is associated with zero or more schedules. A
1801
schedule is used to specify when the query (specified below) is to be
1802
run. A new event starts out with no schedules (which means it will
1803
never run, as it is not scheduled to run). To add a schedule, press
1804
the "Add a new schedule" button.
1808
Each schedule includes an interval, which you use to tell Bugzilla
1809
when the event should be run. An event can be run on certain days of
1810
the week, certain days of the month, during weekdays (defined as
1811
Monday through Friday), or every day.
1816
Be careful if you set your event to run on the 29th, 30th, or 31st of
1817
the month, as your event may not run exactly when expected. If you
1818
want your event to run on the last day of the month, select "Last day
1819
of the month" as the interval.
1824
Once you have specified the day(s) on which the event is to be run, you
1825
should now specify the time at which the event is to be run. You can
1826
have the event run at a certain hour on the specified day(s), or
1827
every hour, half-hour, or quarter-hour on the specified day(s).
1831
If a single schedule does not execute an event as many times as you
1832
would want, you can create another schedule for the same event. For
1833
example, if you want to run an event on days whose numbers are
1834
divisible by seven, you would need to add four schedules to the event,
1835
setting the schedules to run on the 7th, 14th, 21st, and 28th (one day
1836
per schedule) at whatever time (or times) you choose.
1841
If you are a member of the bz_canusewhineatothers group, then you
1842
will be presented with another option: "Mail to". Using this you
1843
can control who will receive the emails generated by this event. You
1844
can choose to send the emails to a single user (identified by email
1845
address) or a single group (identified by group name). To send to
1846
multiple users or groups, create a new schedule for each additional
1852
<section id="whining-query">
1853
<title>Whining Searches</title>
1856
Each whining event is associated with zero or more searches. A search
1857
is any saved search to be run as part of the specified schedule (see
1858
above). You start out without any searches associated with the event
1859
(which means that the event will not run, as there will never be any
1860
results to return). To add a search, press the "Include search" button.
1864
The first field to examine in your newly added search is the Sort field.
1865
Searches are run, and results included, in the order specified by the
1866
Sort field. Searches with smaller Sort values will run before searches
1867
with bigger Sort values.
1871
The next field to examine is the Search field. This is where you
1872
choose the actual search that is to be run. Instead of defining search
1873
parameters here, you are asked to choose from the list of saved
1874
searches (the same list that appears at the bottom of every Bugzilla
1875
page). You are only allowed to choose from searches that you have
1876
saved yourself (the default saved search, "My Bugs", is not a valid
1877
choice). If you do not have any saved searches, you can take this
1878
opportunity to create one (see <xref linkend="list"/>).
1883
When running queries, the whining system acts as if you are the user
1884
executing the query. This means that the whining system will ignore
1885
bugs that match your query, but that you can not access.
1890
Once you have chosen the saved search to be executed, give the query a
1891
descriptive title. This title will appear in the email, above the
1892
results of the query. If you choose "One message per bug", the query
1893
title will appear at the top of each email that contains a bug matching
1898
Finally, decide if the results of the query should be sent in a single
1899
email, or if each bug should appear in its own email.
1904
Think carefully before checking the "One message per bug" box. If
1905
you create a query that matches thousands of bugs, you will receive
1906
thousands of emails!
1912
<title>Saving Your Changes</title>
1915
Once you have defined at least one schedule, and created at least one
1916
query, go ahead and "Update/Commit". This will save your Event and make
1917
it available for immediate execution.
1922
If you ever feel like deleting your event, you may do so using the
1923
"Remove Event" button in the upper-right corner of each Event. You
1924
can also modify an existing event, so long as you "Update/Commit"
1925
after completing your modifications.
1934
<!-- Keep this comment at the end of the file
1937
sgml-always-quote-attributes:t
1938
sgml-auto-insert-required-elements:t
1939
sgml-balanced-tag-edit:t
1940
sgml-exposed-tags:nil
1941
sgml-general-insert-case:lower
1944
sgml-local-catalogs:nil
1945
sgml-local-ecat-files:nil
1946
sgml-minimize-attributes:nil
1947
sgml-namecase-general:t
1949
sgml-parent-document:("Bugzilla-Guide.xml" "book" "chapter")
1951
sgml-tag-region-if-active:t
added
removed
docs/xml/using.xml
