diff options
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/en/xml/Bugzilla-Guide.xml | 4 | ||||
| -rw-r--r-- | docs/en/xml/customization.xml | 8 | ||||
| -rw-r--r-- | docs/en/xml/installation.xml | 4 | ||||
| -rw-r--r-- | docs/en/xml/using.xml | 16 |
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> |