organizations around the world, tracking millions of bugs.
</para>
- <para>
- <warning>
- <para>IMPORTANT: this documentation is currently being
- updated for the Bugzilla 2.16 release and is in an unusual state of
- flux. Even more than normal, don't believe everything,
- or even anything, you read.
- </para>
- </warning>
- </para>
-
<para>
This documentation is maintained in DocBook 4.1.2 XML format.
Changes are best submitted as plain text or SGML diffs, attached
<section>
<title>What to Edit</title>
<para>
- There are several ways to take advantage of Bugzilla's templates,
- and which you use depends on what you want to do. The Bugzilla
+ There are two different ways of editing of Bugzilla's templates,
+ and which you use depends mainly on how you upgrade Bugzilla. The
template directory structure is that there's a top level directory,
<filename>template</filename>, which contains a directory for
each installed localisation. The default English templates are
therefore in <filename>en</filename>. Underneath that, there
- are two directories - <filename>default</filename> and
- <filename>custom</filename> (you may have to create
- <filename>custom</filename> yourself.) The <filename>default</filename>
- directory contains all the templates shipped with Bugzilla.
+ is the <filename>default</filename> directory and optionally the
+ <filename>custom</filename> directory. The <filename>default</filename>
+ directory contains all the templates shipped with Bugzilla, whereas
+ the <filename>custom</filename> directory does not exist at first and
+ must be created if you want to use it.
</para>
<para>
- One method of making customisations is to directly edit the templates
- in <filename>template/en/default</filename>. This is probably the
- best method for small changes, because if you then execute a
+ The first method of making customisations is to directly edit the
+ templates in <filename>template/en/default</filename>. This is
+ probably the best method for small changes if you are going to use
+ the CVS method of upgrading, because if you then execute a
<command>cvs update</command>, any template fixes will get
automagically merged into your modified versions.
</para>
<para>
- The other method is to copy the templates into a mirrored directory
- structure under <filename>template/en/custom</filename>.
- This method is better if
- you 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 changes into the new versions by
- hand. This is also the correct method to use if you upgrade Bugzilla
- by untarring tarballs over the top, rather than using CVS. It's perfectly
- acceptable to mix and match these two methods.
+ If you use this method, your installation will break if CVS conflicts
+ occur.
</para>
<para>
- Editing templates is a good way of doing a "poor man's custom fields".
- For example, if you don't use the Status Whiteboard, but want to have
- a free-form text entry box for "Build Identifier", then you can just
- edit the templates to change the field labels. It's still be called
- status_whiteboard internally, but your users don't need to know that.
+ The other method is to copy the templates into a mirrored directory
+ structure under <filename>template/en/custom</filename>. The templates
+ in this directory automatically override those in default.
+ This is the technique you
+ need to use if you use the overwriting method of upgrade, because
+ otherwise your changes will be lost. This method is also better if
+ you are using the CVS 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
+ changes into the new versions by hand.
</para>
-
+
<para>
- If you are making changes to contribute back to Bugzilla (and we'd
- love to have them), then please read the
- <ulink url="http://www.bugzilla.org/developerguide.html">Developers
- Guide</ulink> first.
+ If you use this method, your installation may break if incompatible
+ changes are made to the template interface. If such changes are made
+ they will be documented in the release notes, provided you are using a
+ stable release of Bugzilla. If you use using unstable code, you will
+ need to deal with this one yourself, although if possible the changes
+ will be mentioned before they occur in the deprecations section of the
+ previous stable release's release notes.
</para>
+
+ <note>
+ <para>
+ Don't directly edit the compiled templates in
+ <filename class="directory">data/template/*</filename> - your
+ changes will be lost when Template Toolkit recompiles them.
+ </para>
+ </note>
+ </section>
+
+ <section>
+ <title>How To Edit Templates</title>
<para>
The syntax of the Template Toolkit language is beyond the scope of
user input, to prevent cross-site scripting attacks.
</para>
+ <para>
+ However, one thing you should take particular care about is the need
+ to properly HTML filter data that has been passed into the template.
+ This means that if the data can possibly contain special HTML characters
+ such as <, and the data was not intended to be HTML, they need to be
+ converted to entity form, ie &lt;. You use the 'html' filter in the
+ Template Toolkit to do this. If you fail to do this, you may open up
+ your installation to cross-site scripting attacks.
+ </para>
+
+ <para>
+ Also note that Bugzilla adds a few filters of its own, that are not
+ in standard Template Toolkit. In particular, the 'url_quote' filter
+ can convert characters that are illegal or have special meaning in URLs,
+ such as &, to the encoded form, ie %26. This actually encodes most
+ characters (but not the common ones such as letters and numbers and so
+ on), including the HTML-special characters, so there's never a need to
+ HTML filter afterwards.
+ </para>
+
+ <para>
+ Editing templates is a good way of doing a "poor man's custom fields".
+ For example, if you don't use the Status Whiteboard, but want to have
+ a free-form text entry box for "Build Identifier", then you can just
+ edit the templates to change the field labels. It's still be called
+ status_whiteboard internally, but your users don't need to know that.
+ </para>
+
<note>
<para>
- Don't directly edit the compiled templates in
- <filename class="directory">data/template/*</filename> - your
- changes will be lost when Template Toolkit recompiles them.
+ If you are making template changes that you intend on submitting back
+ for inclusion in standard Bugzilla, you should read the relevant
+ sections of the
+ <ulink url="http://www.bugzilla.org/developerguide.html">Developers'
+ Guide</ulink>.
</para>
</note>
</section>
</para>
<para>
- <command>global/header.html.tmpl</command> and
+ <command>global/header.html.tmpl</command>:
+ This defines the header that goes on all Bugzilla pages.
+ The header includes the banner, which is what appears to users
+ and is probably what you want to edit instead. However the
+ header also includes the HTML HEAD section, so you could for
+ example add a stylesheet or META tag by editing the header.
+ </para>
+
+ <para>
+ <command>global/banner.html.tmpl</command>:
+ This contains the "banner", the part of the header that appears
+ at the top of all Bugzilla pages. The default banner is reasonably
+ barren, so you'll probably want to customise this to give your
+ installation a distinctive look and feel. It is recommended you
+ preserve the Bugzilla version number in some form so the version
+ you are running can be determined, and users know what docs to read.
+ </para>
+
+ <para>
<command>global/footer.html.tmpl</command>:
- These define the header and footer that go on all Bugzilla pages.
- Editing these is a way to quickly get a distinctive look and
- feel for your Bugzilla installation.
- </para>
+ This defines the footer that goes on all Bugzilla pages. Editing
+ this is another way to quickly get a distinctive look and feel for
+ your Bugzilla installation.
+ </para>
+ <para>
+ <command>bug/create/user-message.html.tmpl</command>:
+ This is a message that appears near the top of the bug reporting page.
+ By modifying this, you can tell your users how they should report
+ bugs.
+ </para>
+
<para>
<command>bug/create/create.html.tmpl</command> and
<command>bug/create/comment.txt.tmpl</command>:
<ulink url="http://bugzilla.mozilla.org/enter_bug.cgi?format=guided">guided
bug submission form</ulink>.
</para>
-
+
<para>
To make this work, create a custom template for
<filename>enter_bug.cgi</filename> (the default template, on which you
<entry>Code Example</entry>
<entry>
- <programlisting>
-<sgmltag class="starttag">para</sgmltag>
+ <programlisting><sgmltag class="starttag">para</sgmltag>
Beginning and end of paragraph
-<sgmltag class="endtag">para</sgmltag>
- </programlisting>
+<sgmltag class="endtag">para</sgmltag></programlisting>
</entry>
</row>
</tbody>
non-English-speaking Bugzilla sites, I suggest changing
<quote>ISO-8859-1</quote>, above, to
<quote>UTF-8</quote>.</para>
+
+ <para>Note: using <meta> tags to set the charset is not
+ recommended, as there's a bug in Netscape 4.x which causes pages
+ marked up in this way to load twice.</para>
</section>
<section id="htaccess" xreflabel=".htaccess files and security">
<section id="win32" xreflabel="Win32 Installation Notes">
<title>Win32 Installation Notes</title>
- <para>This section covers installation on Microsoft Windows 95, 98, ME,
- NT, and 2000. Bugzilla works fine on Win32 platforms, but please remember
- that the Bugzilla team and the author of the Guide neither endorse nor
- support installation on Microsoft Windows. Bugzilla installs and runs
- <emphasis>best</emphasis>
-
- and
- <emphasis>easiest</emphasis>
-
- on UNIX-like operating systems, and that is the way it will stay for the
- foreseeable future. The Bugzilla team is considering supporting Win32 for
- the 2.16 release and later.</para>
-
- <para>The easiest way to install Bugzilla on Intel-archiecture machines
+ <para>This section covers installation on Microsoft Windows.
+ Bugzilla has been made to work on Win32 platforms, but the Bugzilla team
+ wish to emphasise that The easiest way to install Bugzilla on
+ Intel-archiecture machines
is to install some variant of GNU/Linux, then follow the UNIX
installation instructions in this Guide. If you have any influence in the
platform choice for running this system, please choose GNU/Linux instead
of Microsoft Windows.</para>
+ <warning>
+ <para>After that warning, here's the situation for 2.16
+ and Windows. It doesn't work at all out of the box.
+ You are almost certainly better off getting
+ the 2.17 version from CVS (after consultation with the Bugzilla Team to
+ make sure you are pulling on a stable day) because we'll be doing a load
+ of work to make the Win32 experience more pleasant than it is now.
+ </para>
+ </warning>
+
+ <para>
+ If you still want to try this, to have any hope of getting it to work,
+ you'll need to apply the
+ <ulink url="">mail patch</ulink> from
+ <ulink url="http://bugzilla.mozilla.org/show_bug.cgi?id=124174">bug 124174</ulink>.
+ After that, you'll need to read the (outdated) installation
+ instructions below, some (probably a lot better) <ulink url="http://bugzilla.mozilla.org/attachment.cgi?id=84430&action=view">more
+ recent ones</ulink> kindly provided by Toms Baugis and Jean-Sebastien
+ Guay, and also check the
+ <ulink url="http://www.bugzilla.org/releases/2.16/docs/win32.html">Bugzilla 2.16 Win32 update page
+ </ulink>. If we get time,
+ we'll write some better installation instructions for 2.16 and put
+ them up there. But no promises.
+ </para>
+
<section id="wininstall" xreflabel="Win32 Installation: Step-by-step">
<title>Win32 Installation: Step-by-step</title>
problems.
</para>
+ <section>
+ <title>Bundle::Bugzilla makes me upgrade to Perl 5.6.1</title>
+
+ <para>
+ Try executing <command>perl -MCPAN -e 'install CPAN'</command>
+ and then continuing.
+ </para>
+
+ <para>
+ Certain older versions of the CPAN toolset were somewhat naive about how
+ to upgrade Perl modules. When a couple of modules got rolled into the core
+ Perl distribution for 5.6.1, CPAN thought that the best way to get those
+ modules up to date was to haul down the Perl distribution itself and
+ build it. Needless to say, this has caused headaches for just about
+ everybody. Upgrading to a newer version of CPAN with the
+ commandline above should fix things.
+ </para>
+ </section>
+
+
<section>
<title>DBD::Sponge::db prepare failed</title>
management, chip design and development problem tracking (both
pre-and-post fabrication), and software and hardware bug tracking for
luminaries such as Redhat, NASA, Linux-Mandrake, and VA Systems.
- Combined with systems such as CVS, Bonsai, or Perforce SCM, Bugzilla
+ Combined with systems such as
+ <ulink url="http://www.cvshome.org">CVS</ulink>,
+ <ulink url="http://www.mozilla.org/bonsai.html">Bonsai</ulink>, or
+ <ulink url="http://www.perforce.com">Perforce SCM</ulink>, Bugzilla
provides a powerful, easy-to-use solution to configuration management and
replication problems.</para>
<para>This section contains information for end-users of Bugzilla.
There is a Bugzilla test installation, called
- <ulink url="http://landfill.tequilarista.org/">Landfill</ulink>,
+ <ulink url="http://landfill.bugzilla.org/">Landfill</ulink>,
which you are welcome to play with (if it's up.)
However, it does not necessarily
have all Bugzilla features enabled, and often runs cutting-edge versions
Consult with the administrator responsible for your installation of
Bugzilla for the URL you should use to access it. If you're
test-driving Bugzilla, use this URL:
- <ulink url="http://landfill.tequilarista.org/bugzilla-tip/">
- http://landfill.tequilarista.org/bugzilla-tip/</ulink>
+ <ulink url="http://landfill.bugzilla.org/bugzilla-tip/">
+ http://landfill.bugzilla.org/bugzilla-tip/</ulink>
</para>
<orderedlist>
<para>The core of Bugzilla is the screen which displays a particular
bug. It's a good place to explain some Bugzilla concepts.
<ulink
- url="http://landfill.tequilarista.org/bugzilla-tip/show_bug.cgi?id=1">
+ url="http://landfill.bugzilla.org/bugzilla-tip/show_bug.cgi?id=1">
Bug 1 on Landfill</ulink>
is a good example. Note that the labels for most fields are hyperlinks;
<para>The Bugzilla Search page is is the interface where you can find
any bug report, comment, or patch currently in the Bugzilla system. You
can play with it here:
- <ulink url="http://landfill.tequilarista.org/bugzilla-tip/query.cgi">
- landfill.tequilarista.org/bugzilla-tip/query.cgi</ulink>
+ <ulink url="http://landfill.bugzilla.org/bugzilla-tip/query.cgi">
+ landfill.bugzilla.org/bugzilla-tip/query.cgi</ulink>
.</para>
<para>Highly advanced querying is done using Boolean Charts, which have
their own
<ulink
- url="http://landfill.tequilarista.org/bugzilla-tip/booleanchart.html">
+ url="http://landfill.bugzilla.org/bugzilla-tip/booleanchart.html">
context-sensitive help</ulink>
.</para>
<para>Years of bug writing experience has been distilled for your
reading pleasure into the
<ulink
- url="http://landfill.tequilarista.org/bugzilla-tip/bugwritinghelp.html">
+ url="http://landfill.bugzilla.org/bugzilla-tip/bugwritinghelp.html">
Bug Writing Guidelines</ulink>.
While some of the advice is Mozilla-specific, the basic principles of
reporting Reproducible, Specific bugs, isolating the Product you are
<orderedlist>
<listitem>
<para>Go to
- <ulink url="http://landfill.tequilarista.org/bugzilla-tip/">
+ <ulink url="http://landfill.bugzilla.org/bugzilla-tip/">
Landfill</ulink>
in your browser and click
<ulink
- url="http://landfill.tequilarista.org/bugzilla-tip/enter_bug.cgi">
+ url="http://landfill.bugzilla.org/bugzilla-tip/enter_bug.cgi">
Enter a new bug report</ulink>.
</para>
</listitem>
<section id="rhbugzilla" xreflabel="Red Hat Bugzilla">
<title>Red Hat Bugzilla</title>
- <para>Red Hat Bugzilla is probably the most popular Bugzilla, after
- Bugzilla itself, on the planet. One of the major benefits of Red Hat
- Bugzilla is the ability
+ <para>Red Hat Bugzilla is a fork of Bugzilla 2.8.
+ One of its major benefits is the ability
to work with Oracle, MySQL, and PostGreSQL databases serving as the
back-end, instead of just MySQL. Dave Lawrence of Red Hat is
active in the Bugzilla community, and we hope to see a reunification
<title>Scarab</title>
<para>Scarab is a new open source bug-tracking system built using Java
- Serlet technology. It is currently at version 1.0 beta 7.</para>
+ Serlet technology. It is currently at version 1.0 beta 8.</para>
<para>URL:
<ulink url="http://scarab.tigris.org/">http://scarab.tigris.org</ulink>
organizations around the world, tracking millions of bugs.
</para>
- <para>
- <warning>
- <para>IMPORTANT: this documentation is currently being
- updated for the Bugzilla 2.16 release and is in an unusual state of
- flux. Even more than normal, don't believe everything,
- or even anything, you read.
- </para>
- </warning>
- </para>
-
<para>
This documentation is maintained in DocBook 4.1.2 XML format.
Changes are best submitted as plain text or SGML diffs, attached
<section>
<title>What to Edit</title>
<para>
- There are several ways to take advantage of Bugzilla's templates,
- and which you use depends on what you want to do. The Bugzilla
+ There are two different ways of editing of Bugzilla's templates,
+ and which you use depends mainly on how you upgrade Bugzilla. The
template directory structure is that there's a top level directory,
<filename>template</filename>, which contains a directory for
each installed localisation. The default English templates are
therefore in <filename>en</filename>. Underneath that, there
- are two directories - <filename>default</filename> and
- <filename>custom</filename> (you may have to create
- <filename>custom</filename> yourself.) The <filename>default</filename>
- directory contains all the templates shipped with Bugzilla.
+ is the <filename>default</filename> directory and optionally the
+ <filename>custom</filename> directory. The <filename>default</filename>
+ directory contains all the templates shipped with Bugzilla, whereas
+ the <filename>custom</filename> directory does not exist at first and
+ must be created if you want to use it.
</para>
<para>
- One method of making customisations is to directly edit the templates
- in <filename>template/en/default</filename>. This is probably the
- best method for small changes, because if you then execute a
+ The first method of making customisations is to directly edit the
+ templates in <filename>template/en/default</filename>. This is
+ probably the best method for small changes if you are going to use
+ the CVS method of upgrading, because if you then execute a
<command>cvs update</command>, any template fixes will get
automagically merged into your modified versions.
</para>
<para>
- The other method is to copy the templates into a mirrored directory
- structure under <filename>template/en/custom</filename>.
- This method is better if
- you 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 changes into the new versions by
- hand. This is also the correct method to use if you upgrade Bugzilla
- by untarring tarballs over the top, rather than using CVS. It's perfectly
- acceptable to mix and match these two methods.
+ If you use this method, your installation will break if CVS conflicts
+ occur.
</para>
<para>
- Editing templates is a good way of doing a "poor man's custom fields".
- For example, if you don't use the Status Whiteboard, but want to have
- a free-form text entry box for "Build Identifier", then you can just
- edit the templates to change the field labels. It's still be called
- status_whiteboard internally, but your users don't need to know that.
+ The other method is to copy the templates into a mirrored directory
+ structure under <filename>template/en/custom</filename>. The templates
+ in this directory automatically override those in default.
+ This is the technique you
+ need to use if you use the overwriting method of upgrade, because
+ otherwise your changes will be lost. This method is also better if
+ you are using the CVS 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
+ changes into the new versions by hand.
</para>
-
+
<para>
- If you are making changes to contribute back to Bugzilla (and we'd
- love to have them), then please read the
- <ulink url="http://www.bugzilla.org/developerguide.html">Developers
- Guide</ulink> first.
+ If you use this method, your installation may break if incompatible
+ changes are made to the template interface. If such changes are made
+ they will be documented in the release notes, provided you are using a
+ stable release of Bugzilla. If you use using unstable code, you will
+ need to deal with this one yourself, although if possible the changes
+ will be mentioned before they occur in the deprecations section of the
+ previous stable release's release notes.
</para>
+
+ <note>
+ <para>
+ Don't directly edit the compiled templates in
+ <filename class="directory">data/template/*</filename> - your
+ changes will be lost when Template Toolkit recompiles them.
+ </para>
+ </note>
+ </section>
+
+ <section>
+ <title>How To Edit Templates</title>
<para>
The syntax of the Template Toolkit language is beyond the scope of
user input, to prevent cross-site scripting attacks.
</para>
+ <para>
+ However, one thing you should take particular care about is the need
+ to properly HTML filter data that has been passed into the template.
+ This means that if the data can possibly contain special HTML characters
+ such as <, and the data was not intended to be HTML, they need to be
+ converted to entity form, ie &lt;. You use the 'html' filter in the
+ Template Toolkit to do this. If you fail to do this, you may open up
+ your installation to cross-site scripting attacks.
+ </para>
+
+ <para>
+ Also note that Bugzilla adds a few filters of its own, that are not
+ in standard Template Toolkit. In particular, the 'url_quote' filter
+ can convert characters that are illegal or have special meaning in URLs,
+ such as &, to the encoded form, ie %26. This actually encodes most
+ characters (but not the common ones such as letters and numbers and so
+ on), including the HTML-special characters, so there's never a need to
+ HTML filter afterwards.
+ </para>
+
+ <para>
+ Editing templates is a good way of doing a "poor man's custom fields".
+ For example, if you don't use the Status Whiteboard, but want to have
+ a free-form text entry box for "Build Identifier", then you can just
+ edit the templates to change the field labels. It's still be called
+ status_whiteboard internally, but your users don't need to know that.
+ </para>
+
<note>
<para>
- Don't directly edit the compiled templates in
- <filename class="directory">data/template/*</filename> - your
- changes will be lost when Template Toolkit recompiles them.
+ If you are making template changes that you intend on submitting back
+ for inclusion in standard Bugzilla, you should read the relevant
+ sections of the
+ <ulink url="http://www.bugzilla.org/developerguide.html">Developers'
+ Guide</ulink>.
</para>
</note>
</section>
</para>
<para>
- <command>global/header.html.tmpl</command> and
+ <command>global/header.html.tmpl</command>:
+ This defines the header that goes on all Bugzilla pages.
+ The header includes the banner, which is what appears to users
+ and is probably what you want to edit instead. However the
+ header also includes the HTML HEAD section, so you could for
+ example add a stylesheet or META tag by editing the header.
+ </para>
+
+ <para>
+ <command>global/banner.html.tmpl</command>:
+ This contains the "banner", the part of the header that appears
+ at the top of all Bugzilla pages. The default banner is reasonably
+ barren, so you'll probably want to customise this to give your
+ installation a distinctive look and feel. It is recommended you
+ preserve the Bugzilla version number in some form so the version
+ you are running can be determined, and users know what docs to read.
+ </para>
+
+ <para>
<command>global/footer.html.tmpl</command>:
- These define the header and footer that go on all Bugzilla pages.
- Editing these is a way to quickly get a distinctive look and
- feel for your Bugzilla installation.
- </para>
+ This defines the footer that goes on all Bugzilla pages. Editing
+ this is another way to quickly get a distinctive look and feel for
+ your Bugzilla installation.
+ </para>
+ <para>
+ <command>bug/create/user-message.html.tmpl</command>:
+ This is a message that appears near the top of the bug reporting page.
+ By modifying this, you can tell your users how they should report
+ bugs.
+ </para>
+
<para>
<command>bug/create/create.html.tmpl</command> and
<command>bug/create/comment.txt.tmpl</command>:
<ulink url="http://bugzilla.mozilla.org/enter_bug.cgi?format=guided">guided
bug submission form</ulink>.
</para>
-
+
<para>
To make this work, create a custom template for
<filename>enter_bug.cgi</filename> (the default template, on which you
<entry>Code Example</entry>
<entry>
- <programlisting>
-<sgmltag class="starttag">para</sgmltag>
+ <programlisting><sgmltag class="starttag">para</sgmltag>
Beginning and end of paragraph
-<sgmltag class="endtag">para</sgmltag>
- </programlisting>
+<sgmltag class="endtag">para</sgmltag></programlisting>
</entry>
</row>
</tbody>
non-English-speaking Bugzilla sites, I suggest changing
<quote>ISO-8859-1</quote>, above, to
<quote>UTF-8</quote>.</para>
+
+ <para>Note: using <meta> tags to set the charset is not
+ recommended, as there's a bug in Netscape 4.x which causes pages
+ marked up in this way to load twice.</para>
</section>
<section id="htaccess" xreflabel=".htaccess files and security">
<section id="win32" xreflabel="Win32 Installation Notes">
<title>Win32 Installation Notes</title>
- <para>This section covers installation on Microsoft Windows 95, 98, ME,
- NT, and 2000. Bugzilla works fine on Win32 platforms, but please remember
- that the Bugzilla team and the author of the Guide neither endorse nor
- support installation on Microsoft Windows. Bugzilla installs and runs
- <emphasis>best</emphasis>
-
- and
- <emphasis>easiest</emphasis>
-
- on UNIX-like operating systems, and that is the way it will stay for the
- foreseeable future. The Bugzilla team is considering supporting Win32 for
- the 2.16 release and later.</para>
-
- <para>The easiest way to install Bugzilla on Intel-archiecture machines
+ <para>This section covers installation on Microsoft Windows.
+ Bugzilla has been made to work on Win32 platforms, but the Bugzilla team
+ wish to emphasise that The easiest way to install Bugzilla on
+ Intel-archiecture machines
is to install some variant of GNU/Linux, then follow the UNIX
installation instructions in this Guide. If you have any influence in the
platform choice for running this system, please choose GNU/Linux instead
of Microsoft Windows.</para>
+ <warning>
+ <para>After that warning, here's the situation for 2.16
+ and Windows. It doesn't work at all out of the box.
+ You are almost certainly better off getting
+ the 2.17 version from CVS (after consultation with the Bugzilla Team to
+ make sure you are pulling on a stable day) because we'll be doing a load
+ of work to make the Win32 experience more pleasant than it is now.
+ </para>
+ </warning>
+
+ <para>
+ If you still want to try this, to have any hope of getting it to work,
+ you'll need to apply the
+ <ulink url="">mail patch</ulink> from
+ <ulink url="http://bugzilla.mozilla.org/show_bug.cgi?id=124174">bug 124174</ulink>.
+ After that, you'll need to read the (outdated) installation
+ instructions below, some (probably a lot better) <ulink url="http://bugzilla.mozilla.org/attachment.cgi?id=84430&action=view">more
+ recent ones</ulink> kindly provided by Toms Baugis and Jean-Sebastien
+ Guay, and also check the
+ <ulink url="http://www.bugzilla.org/releases/2.16/docs/win32.html">Bugzilla 2.16 Win32 update page
+ </ulink>. If we get time,
+ we'll write some better installation instructions for 2.16 and put
+ them up there. But no promises.
+ </para>
+
<section id="wininstall" xreflabel="Win32 Installation: Step-by-step">
<title>Win32 Installation: Step-by-step</title>
problems.
</para>
+ <section>
+ <title>Bundle::Bugzilla makes me upgrade to Perl 5.6.1</title>
+
+ <para>
+ Try executing <command>perl -MCPAN -e 'install CPAN'</command>
+ and then continuing.
+ </para>
+
+ <para>
+ Certain older versions of the CPAN toolset were somewhat naive about how
+ to upgrade Perl modules. When a couple of modules got rolled into the core
+ Perl distribution for 5.6.1, CPAN thought that the best way to get those
+ modules up to date was to haul down the Perl distribution itself and
+ build it. Needless to say, this has caused headaches for just about
+ everybody. Upgrading to a newer version of CPAN with the
+ commandline above should fix things.
+ </para>
+ </section>
+
+
<section>
<title>DBD::Sponge::db prepare failed</title>
management, chip design and development problem tracking (both
pre-and-post fabrication), and software and hardware bug tracking for
luminaries such as Redhat, NASA, Linux-Mandrake, and VA Systems.
- Combined with systems such as CVS, Bonsai, or Perforce SCM, Bugzilla
+ Combined with systems such as
+ <ulink url="http://www.cvshome.org">CVS</ulink>,
+ <ulink url="http://www.mozilla.org/bonsai.html">Bonsai</ulink>, or
+ <ulink url="http://www.perforce.com">Perforce SCM</ulink>, Bugzilla
provides a powerful, easy-to-use solution to configuration management and
replication problems.</para>
<para>This section contains information for end-users of Bugzilla.
There is a Bugzilla test installation, called
- <ulink url="http://landfill.tequilarista.org/">Landfill</ulink>,
+ <ulink url="http://landfill.bugzilla.org/">Landfill</ulink>,
which you are welcome to play with (if it's up.)
However, it does not necessarily
have all Bugzilla features enabled, and often runs cutting-edge versions
Consult with the administrator responsible for your installation of
Bugzilla for the URL you should use to access it. If you're
test-driving Bugzilla, use this URL:
- <ulink url="http://landfill.tequilarista.org/bugzilla-tip/">
- http://landfill.tequilarista.org/bugzilla-tip/</ulink>
+ <ulink url="http://landfill.bugzilla.org/bugzilla-tip/">
+ http://landfill.bugzilla.org/bugzilla-tip/</ulink>
</para>
<orderedlist>
<para>The core of Bugzilla is the screen which displays a particular
bug. It's a good place to explain some Bugzilla concepts.
<ulink
- url="http://landfill.tequilarista.org/bugzilla-tip/show_bug.cgi?id=1">
+ url="http://landfill.bugzilla.org/bugzilla-tip/show_bug.cgi?id=1">
Bug 1 on Landfill</ulink>
is a good example. Note that the labels for most fields are hyperlinks;
<para>The Bugzilla Search page is is the interface where you can find
any bug report, comment, or patch currently in the Bugzilla system. You
can play with it here:
- <ulink url="http://landfill.tequilarista.org/bugzilla-tip/query.cgi">
- landfill.tequilarista.org/bugzilla-tip/query.cgi</ulink>
+ <ulink url="http://landfill.bugzilla.org/bugzilla-tip/query.cgi">
+ landfill.bugzilla.org/bugzilla-tip/query.cgi</ulink>
.</para>
<para>Highly advanced querying is done using Boolean Charts, which have
their own
<ulink
- url="http://landfill.tequilarista.org/bugzilla-tip/booleanchart.html">
+ url="http://landfill.bugzilla.org/bugzilla-tip/booleanchart.html">
context-sensitive help</ulink>
.</para>
<para>Years of bug writing experience has been distilled for your
reading pleasure into the
<ulink
- url="http://landfill.tequilarista.org/bugzilla-tip/bugwritinghelp.html">
+ url="http://landfill.bugzilla.org/bugzilla-tip/bugwritinghelp.html">
Bug Writing Guidelines</ulink>.
While some of the advice is Mozilla-specific, the basic principles of
reporting Reproducible, Specific bugs, isolating the Product you are
<orderedlist>
<listitem>
<para>Go to
- <ulink url="http://landfill.tequilarista.org/bugzilla-tip/">
+ <ulink url="http://landfill.bugzilla.org/bugzilla-tip/">
Landfill</ulink>
in your browser and click
<ulink
- url="http://landfill.tequilarista.org/bugzilla-tip/enter_bug.cgi">
+ url="http://landfill.bugzilla.org/bugzilla-tip/enter_bug.cgi">
Enter a new bug report</ulink>.
</para>
</listitem>
<section id="rhbugzilla" xreflabel="Red Hat Bugzilla">
<title>Red Hat Bugzilla</title>
- <para>Red Hat Bugzilla is probably the most popular Bugzilla, after
- Bugzilla itself, on the planet. One of the major benefits of Red Hat
- Bugzilla is the ability
+ <para>Red Hat Bugzilla is a fork of Bugzilla 2.8.
+ One of its major benefits is the ability
to work with Oracle, MySQL, and PostGreSQL databases serving as the
back-end, instead of just MySQL. Dave Lawrence of Red Hat is
active in the Bugzilla community, and we hope to see a reunification
<title>Scarab</title>
<para>Scarab is a new open source bug-tracking system built using Java
- Serlet technology. It is currently at version 1.0 beta 7.</para>
+ Serlet technology. It is currently at version 1.0 beta 8.</para>
<para>URL:
<ulink url="http://scarab.tigris.org/">http://scarab.tigris.org</ulink>
projects / thirdparty / bugzilla.git / commitdiff
