summaryrefslogtreecommitdiffstats
path: root/docs
diff options
context:
space:
mode:
Diffstat (limited to 'docs')
-rw-r--r--docs/en/xml/Bugzilla-Guide.xml4
-rw-r--r--docs/en/xml/customization.xml8
-rw-r--r--docs/en/xml/installation.xml4
-rw-r--r--docs/en/xml/using.xml16
4 files changed, 13 insertions, 19 deletions
diff --git a/docs/en/xml/Bugzilla-Guide.xml b/docs/en/xml/Bugzilla-Guide.xml
index 1ed72f64a..e8497962d 100644
--- a/docs/en/xml/Bugzilla-Guide.xml
+++ b/docs/en/xml/Bugzilla-Guide.xml
@@ -32,9 +32,9 @@
For a devel release, simple bump bz-ver and bz-date
-->
-<!ENTITY bz-ver "4.2.3">
+<!ENTITY bz-ver "4.2.4">
<!ENTITY bz-nextver "4.4">
-<!ENTITY bz-date "2012-08-30">
+<!ENTITY bz-date "2012-11-13">
<!ENTITY current-year "2012">
<!ENTITY landfillbase "http://landfill.bugzilla.org/bugzilla-4.2-branch/">
diff --git a/docs/en/xml/customization.xml b/docs/en/xml/customization.xml
index 9b62b1d0b..c1524e07d 100644
--- a/docs/en/xml/customization.xml
+++ b/docs/en/xml/customization.xml
@@ -110,14 +110,14 @@
The first method of making customizations is to directly edit the
templates found in <filename>template/en/default</filename>.
This is probably the best way to go about it if you are going to
- be upgrading Bugzilla through CVS, because if you then execute
- a <command>cvs update</command>, any changes you have made will
+ be upgrading Bugzilla through Bzr, because if you then execute
+ a <command>bzr update</command>, any changes you have made will
be merged automagically with the updated versions.
</para>
<note>
<para>
- If you use this method, and CVS conflicts occur during an
+ If you use this method, and Bzr conflicts occur during an
update, the conflicted templates (and possibly other parts
of your installation) will not work until they are resolved.
</para>
@@ -143,7 +143,7 @@
The second method of customization should be used if you
use the overwriting method of upgrade, because otherwise
your changes will be lost. This method may also be better if
- you are using the CVS method of upgrading and are going to make major
+ you are using the Bzr method of upgrading and are going to make major
changes, because it is guaranteed that the contents of this directory
will not be touched during an upgrade, and you can then decide whether
to continue using your own templates, or make the effort to merge your
diff --git a/docs/en/xml/installation.xml b/docs/en/xml/installation.xml
index e9830e29c..2da3a8e79 100644
--- a/docs/en/xml/installation.xml
+++ b/docs/en/xml/installation.xml
@@ -191,8 +191,8 @@
<para>
<ulink url="http://www.bugzilla.org/download/">Download a Bugzilla tarball</ulink>
- (or check it out from CVS) and place
- it in a suitable directory, accessible by the default web server user
+ (or <ulink url="https://wiki.mozilla.org/Bugzilla:Bzr">check it out from Bzr</ulink>)
+ and place it in a suitable directory, accessible by the default web server user
(probably <quote>apache</quote> or <quote>www</quote>).
Good locations are either directly in the web server's document directories or
in <filename>/usr/local</filename> with a symbolic link to the web server's
diff --git a/docs/en/xml/using.xml b/docs/en/xml/using.xml
index 3bf0558fc..bed776dd3 100644
--- a/docs/en/xml/using.xml
+++ b/docs/en/xml/using.xml
@@ -665,14 +665,10 @@
<title>Adding/removing tags to/from bugs</title>
<para>
You can add and remove tags from individual bugs, which let you find and
- manage them more easily. Creating a new tag automatically generates a saved
- search - whose name is the name of the tag - which lists bugs with this tag.
- This saved search will be displayed in the footer of pages by default, as
- all other saved searches. The main difference between tags and normal saved
- searches is that saved searches, as described in the previous section, are
- stored in the form of a list of matching criteria, while the saved search
- generated by tags is a list of bug numbers. Consequently, you can easily
- edit this list by either adding or removing tags from bugs. To enable this
+ manage bugs more easily. Tags are per-user and so are only visible and editable
+ by the user who created them. You can then run queries using tags as a criteria,
+ either by using the Advanced Search form, or simply by typing "tag:my_tag_name"
+ in the QuickSearch box at the top (or bottom) of the page. To enable this
feature, you have to turn on the <quote>Enable tags for bugs</quote> user
preference, see <xref linkend="userpreferences" />. This feature is disabled
by default.
@@ -684,9 +680,7 @@
these bugs and mixing all these reasons, you can now store these bugs in
separate lists, e.g. <quote>Keep in mind</quote>, <quote>Interesting bugs</quote>,
or <quote>Triage</quote>. One big advantage of this way to manage bugs
- is that you can easily add or remove bugs one by one, which is not
- possible to do with saved searches without having to edit the search
- criteria again.
+ is that you can easily add or remove tags from bugs one by one.
</para>
</section>
</section>