|
|
Line 1: |
Line 1: |
| '''Note:''' In order to commit you must have bzr 1.17 or later. 2.0 or later is ideal, as it will be faster.
| | As of 2014/03/11, the repositories of record for Bugzilla are on git.mozilla.org. Bugzilla follows a [http://git-scm.com/book/en/Distributed-Git-Distributed-Workflows#Centralized-Workflow centralized work flow]; all commits must be pushed to git.mozilla.org. Some Bugzilla repositories are also mirrored, read-only, to bzr.mozilla.org and, eventually, github.com. |
| | |
| | These instructions are specific to the [http://git.mozilla.org/?p=bugzilla/bugzilla.git;a=summary core Bugzilla repository] but also apply, suitably modified, to [http://git.mozilla.org/?p=bugzilla/qa.git;a=summary qa] and other Bugzilla-related repos. |
|
| |
|
| Here's how to commit a patch:
| | To gain commit rights, you'll need to become a [http://www.mozilla.org/hacking/committer/ Mozilla Committer]. For Bugzilla, the requirement is that one of the Assistant Project Leads or the Project Lead vouch for you. Your bug should be filed in the [https://bugzilla.mozilla.org/enter_bug.cgi?product=mozilla.org&component=Repository+Account+Requests Repository Account Requests] component. ('''Note:''' If you are already a Mozilla Committer and you just need Bzr access, just file a bug in this component requesting it and CC one of the Bugzilla leads.) |
|
| |
|
| #Become a [http://www.mozilla.org/hacking/committer/ Mozilla Committer]. For Bugzilla, the requirement is that one of the Assistant Project Leads or the Project Lead vouch for you. Your bug should be filed in the [https://bugzilla.mozilla.org/enter_bug.cgi?product=mozilla.org&component=Repository+Account+Requests Repository Account Requests] component. ('''Note:''' If you are already a Mozilla Committer and you just need Bzr access, just file a bug in this component requesting it and CC one of the Bugzilla leads.)
| | Make sure you've identified yourself via [http://git-scm.com/book/en/Getting-Started-First-Time-Git-Setup git config]. |
| #If you have never told bzr your name and email address, you have to use "bzr whoami" to do this: <pre>bzr whoami 'Max Kanat-Alexander <mkanat@bugzilla.org>'</pre> (Of course, you would replace that name and email address with your own.) The email address that you use must be identical to your login name for bzr.mozilla.org.<br><br>Please include both your full name and your email address in the "whoami", because your full name is what is displayed in the web view of the repository.
| | |
| #Configure bzr to know about bugzilla.mozilla.org as a bug-tracker (this will be important when you get to the actual commit step). To do this, edit the <code>.bazaar/bazaar.conf</code> file in your home directory and add this line at the end: <pre>bugzilla_mozilla_url = https://bugzilla.mozilla.org</pre> (If you're on Windows, this file is in <code>C:\Documents and Settings\<username>\Application Data\Bazaar\2.0</code> instead of in <code>$HOME/.bazaar</code>.)
| | Before pushing, make sure your commit message is of the form |
| #Get a checkout of Bugzilla using <code>bzr+ssh://</code> (not just <code>bzr://</code>): <pre>bzr co bzr+ssh://username@domain.com@bzr.mozilla.org/bugzilla/trunk bugzilla</pre> Note: If you want to avoid including your username every time you do a checkout over bzr+ssh, you can edit <code>$HOME/.ssh/config</code> and add the following lines:<br><br><code>Host bzr.mozilla.org<br> User username@domain.com</code><br><br>If you fail to use bzr+ssh, when you try and modify the repo you will get the unhelpful error: <code>bzr: ERROR: Cannot lock LockDir(filtered-145825772:///bugzilla/some/path/.bzr/branch/lock): Transport operation not possible: readonly transport</code>
| | |
| #Apply the patch you'll be committing: <pre>cd bugzilla; patch -p0 < patchfile</pre> (Or, if it's a bundle, see the instructions on [[Bugzilla:Patches|applying bundles]].)
| | Bug <id>: <description> |
| #Run "bzr add" to add any files that should be added: <pre>bzr add</pre> If you add the same file on multiple branches, make sure to use the argument <code>--file-ids-from=/path/to/trunk-checkout</code> for all adds that aren't on the trunk.
| | r=<reviewer>, a=<approver> |
| #Check that everything is as it should be: <pre>bzr status</pre>
| | |
| #Commit the patch: <pre>bzr commit --fixes mozilla:123456 --author='Somebody Else <somebody@example.com>'</pre> That number after <code>--fixes</code> is the bug id that the patch fixes. You should specify this with every commit. <code>--author</code> is used only when you are committing somebody else's patch. It lets bzr know who the actual author of the patch is.<br><br>It's very important to remember <code>--fixes</code> and (if necessary) <code>--author</code>--they cannot be set ''after'' you have committed, only while you are committing.
| | Replace <id> and <description> appropriately. '''r=''' indicates the person(s) who reviewed your patch. '''a=''' indicates the person who approved it for check-in. |
| #This will bring up an editor window, using whatever your EDITOR environment variable is set to in your shell. The following instructions assume you use '''vi''', which is the default on many systems. If you use some other editor, refer to the documentation for your editor.<br><br> To start typing in the vi window, press the "i" key on your keyboard. Then you should enter a checkin comment that looks like this: <br><br><code>Bug ''123456'': ''What The Patch Does Goes Here''<br>r=''mkanat'', a=''justdave''</code><br><br> Just replace everything in italics with the right thing. '''r=''' indicates the person(s) who reviewed your patch. '''a=''' indicates the person who approved it for checkin.<br><br> Note that the description given on the checkin comment should describe what the patch actually ''does'' (in a broad sense), which may not necessarily match the summary of the bug being fixed. For example, of the summary of the bug is "Bugzilla doesn't do Foo" then your description in the checkin comment should say something like "Make Bugzilla do Foo". If the first line is longer than 80 characters, manually word-wrap it on to multiple lines.<br><br>To close vi, save the message, and commit your changes, press ESC and then type <code>:wq</code> on the keyboard, and press Enter. If you want to quit without committing (say, you made a mistake and you want to go back), instead of <code>:wq</code> you type <code>:q!</code> (with the exclamation point).
| | |
| #bzr will print out a commit message. Make sure you copy this so you can add it as a comment on the bug when you mark the bug FIXED. Include everything from (and including) the "Committing to:" through the "Committed revision 1234." line.
| | Note that the description given on the commit comment should describe what the patch actually ''does'' (in a broad sense), which may not necessarily match the summary of the bug being fixed. For example, of the summary of the bug is "Bugzilla doesn't do Foo", then your description in the commit comment should say something like "Make Bugzilla do Foo". |
| #Paste the bzr commit message as a comment on the bug and mark it FIXED.
| | |
| | Once you've [http://git-scm.com/book/en/Git-Basics-Recording-Changes-to-the-Repository committed] or [http://git-scm.com/book/en/Git-Branching-Basic-Branching-and-Merging#Basic-Merging merged] to the right branch (usually master) of your local clone, you are ready to push it to git.mozilla.org. Write access is via ssh. Assuming you have already cloned it via the read-only https protocol, you can either add a new remote or update an existing remote: |
| | |
| | git remote add <new remote name> ssh://gitolite3@git.mozilla.org/bugzilla/bugzilla.git |
| | # or if you originally cloned from https |
| | git remote set-url origin ssh://gitolite3@git.mozilla.org/bugzilla/bugzilla.git |
| | |
| | If you ever need to set up a new local repo, you can just [http://git-scm.com/book/en/Git-Basics-Getting-a-Git-Repository#Cloning-an-Existing-Repository clone] it directly: |
| | |
| | git clone ssh://gitolite3@git.mozilla.org/bugzilla/bugzilla.git |
| | |
| | Then push to git.mozilla.org: |
| | |
| | git push <remote name> <branch name> |
| | |
| | <remote name> will be origin if you cloned directly from ssh or used set-url; otherwise it will be the name you gave to git remote add. <branch name> will usually be master, unless you are applying a security or other crucial fix to an older branch. |
| | |
| | After the push successfully completes, paste the output into the bug as a new comment and resolve it FIXED. |
|
| |
|
| [[Category:Bugzilla|S]] | | [[Category:Bugzilla|S]] |