summaryrefslogtreecommitdiffstats
path: root/extensions/Splinter/template/en/default/pages/splinter
diff options
context:
space:
mode:
authorDavid Lawrence <dlawrence@mozilla.com>2011-08-11 00:26:03 +0200
committerDavid Lawrence <dlawrence@mozilla.com>2011-08-11 00:26:03 +0200
commit1f30fac936a3b0905e736dd86e559e33caf036ac (patch)
treeff2e0e3ab03e96dd177ef939304ec8a5b04865e5 /extensions/Splinter/template/en/default/pages/splinter
parent36e4d1fddb336e0ebfb61e0b7870e2b60c666ef5 (diff)
downloadbugzilla-1f30fac936a3b0905e736dd86e559e33caf036ac.tar.gz
bugzilla-1f30fac936a3b0905e736dd86e559e33caf036ac.tar.xz
Initial checkin of bmo/4.0 extensions. Still todo: port changes to core Bugzilla code
Diffstat (limited to 'extensions/Splinter/template/en/default/pages/splinter')
-rw-r--r--extensions/Splinter/template/en/default/pages/splinter/help.html.tmpl153
1 files changed, 153 insertions, 0 deletions
diff --git a/extensions/Splinter/template/en/default/pages/splinter/help.html.tmpl b/extensions/Splinter/template/en/default/pages/splinter/help.html.tmpl
new file mode 100644
index 000000000..bff004c8f
--- /dev/null
+++ b/extensions/Splinter/template/en/default/pages/splinter/help.html.tmpl
@@ -0,0 +1,153 @@
+[%#
+ # The contents of this file are subject to the Mozilla Public
+ # License Version 1.1 (the "License"); you may not use this file
+ # except in compliance with the License. You may obtain a copy of
+ # the License at http://www.mozilla.org/MPL/
+ #
+ # Software distributed under the License is distributed on an "AS
+ # IS" basis, WITHOUT WARRANTY OF ANY KIND, either express or
+ # implied. See the License for the specific language governing
+ # rights and limitations under the License.
+ #
+ # The Original Code is the Splinter Bugzilla Extension.
+ #
+ # The Initial Developer of the Original Code is Red Hat, Inc.
+ # Portions created by Red Hat, Inc. are Copyright (C) 2008
+ # Red Hat, Inc. All Rights Reserved.
+ #
+ # Contributor(s): Owen Taylor <otaylor@redhat.com>
+ #%]
+
+[% PROCESS global/header.html.tmpl
+ title = "Patch Review Help"
+ header = "Patch Review Help"
+%]
+
+<h2>Splinter Patch Review</h2>
+<p>
+ Splinter is an add-on for [% terms.Bugzilla %] to allow conveniently
+ reviewing patches that people have attached to
+ [% terms.Bugzilla %]. <a href="http://fishsoup.net/software/splinter">More
+ information about Splinter</a>.
+</p>
+<h3>The patch review view</h3>
+<p>
+ If you get to Splinter by clicking on a link next to an
+ attachment in [% terms.Bugzilla %], you are presented with the patch
+ review view. This view has a number of different pages that can
+ be switched between with the links at the top of the screen.
+ The first page is the Overview page, the other pages correspond to
+ individual files changed by the review.
+</p>
+<p>
+ On the Overview page, from top to bottom are shown:
+</p>
+<ul>
+ <li>Introductory text to the patch. For a patch that was created
+ using 'git format-patch' this will be the Git commit
+ message.</li>
+ <li>Controls for creating a new review</li>
+ <li>Previous reviews that other people have written.</li>
+</ul>
+<p>
+ The pages for each file show a two-column view of the changes.
+ The left column is the previous contents of the file,
+ the right column is the new contents of the file. (If the file
+ is an entirely new file or an entirely deleted file, only one
+ column will be shown.) Red indicates lines that have been
+ removed, green lines that have been added, and blue lines that
+ were modified.
+</p>
+<p>
+ If people have previously made comments on individual lines of
+ the patch, they will show up both summarized on the Overview
+ page and also inline when looking at the files of the patch.
+</p>
+<h3>Reviewing an existing patch</h3>
+<p>
+ There are three components to a review:
+</p>
+<ul>
+ <li>
+ An overall comment. The text area on the first page allows
+ you to enter your overall thoughts on the [% terms.bug %].
+ </li>
+ <li>
+ Detailed comments on changes within the files. To comment on a
+ line in a patch, double click on it, and a text area will open
+ beneath that comment. When you are done, click the Save button
+ to save your comment or the Cancel button to throw your
+ comment away. You can double-click on a saved comment to start
+ editing it again and make further changes.
+ </li>
+ <li>
+ A change to the attachment status. (This is specific to
+ [% terms.Bugzilla %] instances that have attachment status, which is a
+ non-upstream patch. It's somewhat similar to attachment flags,
+ which splinter doesn't currently support displaying or
+ changing.) This allows you to mark a patch as read to commit
+ or needing additional work. This is done by changing the
+ drop-down next to the Publish button.
+ </li>
+</ul>
+<p>
+ Once you are done writing your review, go back to Overview page
+ and click the "Publish" button to submit it as a comment on the
+ [% terms.bug %]. The comment will have a link back to the review page so
+ that people can see your comments with the full context.
+</p>
+<h3>Saved drafts</h3>
+<p>
+ Whenever you start making changes, a draft is automatically
+ saved. If you come back to the patch review page for the same
+ attachment, that draft will automatically be resumed. Drafts are
+ not visible to anybody else until published.
+</p>
+<p>
+ Note that saving drafts requires the your browser to have support
+ for the "DOM Storage" standard. At time of writing, this is
+ available only in a few very recent browsers, like Firefox
+ 3.5. Strict privacy protections like disabling cookies may also
+ disable DOM Storage, since it provides another mechanism for
+ sites to track information about their users.
+</p>
+<h3>Responding to someone's review</h3>
+<p>
+ A response is treated just like any other review and created the
+ same way. A couple of features are helpful when responding: you
+ can double-click on an inline comment to respond to it. And on
+ the overview page, when you click on a detailed comment, you are
+ taken directly to the original location of the comment.
+</p>
+<h3>Uploading patches for review</h3>
+<p>
+ Splinter doesn't really care how patches are provided to
+ [% terms.Bugzilla %], as long as they are well-formatted patches. If you are
+ using Git for version control, you can either format changes as
+ patches
+ using <a href="http://www.kernel.org/pub/software/scm/git/docs/git-format-patch.html">'git
+ format-patch</a> and attach them manually to the [% terms.bug %], or you
+ can
+ use <a href="http://fishsoup.net/software/git-bz">git-bz</a>.
+ git-bz is highly recommended; it automates most of the steps
+ that Splinter can't handle: it files new [% terms.bugs %], attaches updated
+ attachments to existing [% terms.bugs %], and closes [% terms.bugs %] when you push the
+ corresponding git commits to your central repository.
+</p>
+<h3>The [% terms.bug %] review view</h3>
+<p>
+ Splinter also has a view where it shows all patches attached to
+ the [% terms.bug %] with their status and links to review them. You are
+ taken to this page after publishing a review. You can also get
+ to this page with the [% terms.bug %] link in the upper-right corner of the
+ patch review view.
+</p>
+<h3>Your reviews</h3>
+<p>
+ Splinter can also show you a list of all your draft and
+ published reviews. Access this page with the "Your reviews"
+ link at the bottom of the [% terms.bug %] review view. In-progress drafts
+ are shown in bold.
+</p>
+
+[% PROCESS global/footer.html.tmpl %]