Commit 659ffdc2 authored by lpsolit%gmail.com's avatar lpsolit%gmail.com

Bug 361564: Attachments should have their own section in the docs, and info…

Bug 361564: Attachments should have their own section in the docs, and info about PatchReader should be a sub-section of it - Patch by Fré©ric Buclin <LpSolit@gmail.com> r=Colin
parent 99a4be2c
......@@ -749,6 +749,37 @@
</section>
<section id="attachments">
<title>Attachments</title>
<para>
You should use attachments, rather than comments, for large chunks of ASCII
data, such as trace, debugging output files, or log files. That way, it
doesn't bloat the bug for everyone who wants to read it, and cause people to
receive fat, useless mails.
</para>
<para>You should make sure to trim screenshots. There's no need to show the
whole screen if you are pointing out a single-pixel problem.
</para>
<para>Bugzilla stores and uses a Content-Type for each attachment
(e.g. text/html). To download an attachment as a different
Content-Type (e.g. application/xhtml+xml), you can override this
using a 'content_type' parameter on the URL, e.g.
<filename>&amp;content_type=text/plain</filename>.
</para>
<para>
If you have a really large attachment, something that does not need to
be recorded forever (as most attachments are), you can mark your
attachment as a &quote;Big File&quote;, assuming the administrator of the
installation has enabled this feature. Big Files are stored directly on
disk instead of in the database, and can be deleted when it is no longer
needed. The maximum size of a &quote;Big File&quote; is normally larger
than the maximum size of a regular attachment.
</para>
<section id="patchviewer">
<title>Patch Viewer</title>
......@@ -817,8 +848,7 @@
<para>To link to a section of a patch (for example, if you want to be
able to give someone a URL to show them which part you are talking
about) you simply click the "Link Here" link on the section header. The
resulting URL can be copied and used in discussion. (Copy Link
Location in Mozilla works as well.)</para>
resulting URL can be copied and used in discussion.</para>
</section>
<section id="patchviewer_bonsai_lxr">
......@@ -839,7 +869,7 @@
into a unified diff format by clicking the "Raw Unified" link at the top
of the page.</para>
</section>
</section>
</section>
<section id="hintsandtips">
......@@ -914,44 +944,6 @@
</para>
</section>
<section id="attachments">
<title>Attachments</title>
<para>
Use attachments, rather than comments, for large chunks of ASCII data,
such as trace, debugging output files, or log files. That way, it doesn't
bloat the bug for everyone who wants to read it, and cause people to
receive fat, useless mails.
</para>
<para>Trim screenshots. There's no need to show the whole screen if
you are pointing out a single-pixel problem.
</para>
<para>Don't attach simple test cases (e.g. one HTML file, one
CSS file and an image) as a ZIP file. Instead, upload them in
reverse order and edit the referring file so that they point to the
attached files. This way, the test case works immediately
out of the bug.
</para>
<para>Bugzilla stores and uses a Content-Type for each attachment
(e.g. text/html). To download an attachment as a different
Content-Type (e.g. application/xhtml+xml), you can override this
using a 'content-type' parameter on the URL, e.g.
<filename>&amp;content-type=text/plain</filename>.
</para>
<para>
If you have a really large attachment, something that does not need to
be recorded forever (as most attachments are), you can mark your
attachment as a Big File, Assuming the administrator of the
installation has enabled this feature. Big Files are stored directly on
disk instead of in the database, and can be deleted when it is no longer
needed. The maximum size of a Big File is normally larger than the
maximum size of a regular attachment.
</para>
</section>
<section id="dependencytree">
<title>Dependency Tree</title>
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment