|
|
| (22 intermediate revisions by 10 users not shown) |
| Line 1: |
Line 1: |
| − | __NOTOC__
| |
| − | <<[[TableOfContents]]()>>
| |
| − | = Life with bzr and Launchad =
| |
| | | | |
| − | == Work flow examples ==
| + | <!-- #REDIRECT [[GerritWorkflow]] --> |
| − | | |
| − | === Getting set up ===
| |
| − | | |
| − | The metadata of a bzr commit contains a name and e-mail of the author and committer (usually the same, but can differ). So, you need to let bzr know who you are:
| |
| − | | |
| − | | |
| − | <pre><nowiki>
| |
| − | $ bzr whoami "Soren Hansen <soren.hansen@rackspace.com>
| |
| − | </nowiki></pre>
| |
| − | | |
| − | | |
| − | This will set this user id globally. It can be set on a per-branch basis as well using the --branch option while in the relevant branch:
| |
| − | | |
| − | | |
| − | <pre><nowiki>
| |
| − | $ bzr whoami --branch "Soren Hansen <soren@ubuntu.com>"
| |
| − | </nowiki></pre>
| |
| − | | |
| − | | |
| − | This is useful if you have more than one affiliation.
| |
| − | | |
| − | To make the most of the Launchpad integration, you also tell bzr your Launchpad id:
| |
| − | | |
| − | | |
| − | <pre><nowiki>
| |
| − | $ bzr lp-login soren
| |
| − | </nowiki></pre>
| |
| − | | |
| − | | |
| − | Now you're ready to rock and roll!
| |
| − | | |
| − | === A day in the life of a bzr user ===
| |
| − | | |
| − | '''Note''': We're walking through all of the bits here for completeness, some of the workflow elements are already automated, or are in the process of being automated away)
| |
| − | | |
| − | bzr keeps it branch data in a .bzr in the top level of your source tree. If you expect to have more than one branch of a project (which is usually the case), you start out by creating a top level directory for the project:
| |
| − | | |
| − | | |
| − | <pre><nowiki>
| |
| − | $ mkdir ~/src/novacc
| |
| − | $ cd ~src/novacc
| |
| − | </nowiki></pre>
| |
| − | | |
| − | | |
| − | Now, let bzr know that it should use this for data shared between the individual branches:
| |
| − | | |
| − | | |
| − | <pre><nowiki>
| |
| − | $ bzr init-repo .
| |
| − | </nowiki></pre>
| |
| − | | |
| − | | |
| − | Without this, bzr would copy all the branch data when you create a new branch, so this saves time and space.
| |
| − | | |
| − | Now, check out the project:
| |
| − | | |
| − | | |
| − | <pre><nowiki>
| |
| − | $ bzr branch lp:novacc
| |
| − | </nowiki></pre>
| |
| − | | |
| − | | |
| − | This will grab the designated trunk branch of novacc from Launchpad.
| |
| − | | |
| − | The typical workflow from here is to create a branch specific to the feature or bug you're about to work on. Say we want to work on bug number 765432 on Launchpad and we're not creative enough to come up with a descriptive name for the branch:
| |
| − | | |
| − | | |
| − | <pre><nowiki>
| |
| − | $ bzr branch novacc lp765432
| |
| − | </nowiki></pre>
| |
| − | | |
| − | | |
| − | This will create a new directory, lp765432, with a new working tree in it, ready for hacking.
| |
| − | | |
| − | | |
| − | <pre><nowiki>
| |
| − | $ vim novacc/endpoint/api.py
| |
| − | <hack> <hack>
| |
| − | $ bzr commit --fixes lp:765432 -m 'Updated the url argument sort method to ensure a C locale while sorting.'
| |
| − | </nowiki></pre>
| |
| − | | |
| − | | |
| − | '''Note''': If you omit the -m argument, bzr will open up an editor for you to enter a message, as you would expect.
| |
| − | | |
| − | So far, this branch only lives locally. You want it reviewed, so you push it to Launchpad:
| |
| − | | |
| − | | |
| − | <pre><nowiki>
| |
| − | $ bzr push lp:~soren/novacc/lp765432
| |
| − | </nowiki></pre>
| |
| − | | |
| − | | |
| − | Every user, affiliated with the project or not, can push a novacc branch to Launchpad. No special permissions are required. The general URL form is:
| |
| − | | |
| − | | |
| − | <pre><nowiki>
| |
| − | lp:~username/projectname/branchname
| |
| − | </nowiki></pre>
| |
| − | | |
| − | | |
| − | Once it's been pushed, Launchpad will notice the fact that we specified "--fixes lp:765432" while committing and show a link to the branch in the bug. Anyone subscribed to the bug will get an e-mail about this update.
| |
| − | | |
| − | The branch is immediately visible on Launchpad at https://code.launchpad.net/~soren/novacc/lp765432. You can also get a listing of all of your branches for a particular project at https://code.launchpad.net/~soren/novacc
| |
| − | | |
| − | Note: it's also possible to manually link a bug to a branch from the Launchpad web interface. This is occasionally handy if the bug is tricky and takes a while to fix, and you want people to be able to follow your progress (in case they're curious or perhaps want to help out).
| |
| − | | |
| − | Maybe you decide it needs more work, so you hack on it some more:
| |
| − | | |
| − | | |
| − | <pre><nowiki>
| |
| − | $ vim novacc/endpoint/api.py
| |
| − | <hack> <hack>
| |
| − | $ bzr commit -m 'Try multiple locales while sorting URL arguments to avoid breaking clients that are not careful to do this. This should be considered a temporary fix.'
| |
| − | </nowiki></pre>
| |
| − | | |
| − | | |
| − | Since you've already pushed this branch to Launchpad once before, bzr knows to push it to the same place without more hand holding:
| |
| − | | |
| − | | |
| − | <pre><nowiki>
| |
| − | $ bzr push
| |
| − | </nowiki></pre>
| |
| − | | |
| − | | |
| − | At this point, you want to land this branch into a target branch - typically the trunk branch, but also potentially a long-running feature branch. This can happen in a number of different ways, depending on the project. At Rackspace, the goal is to follow the Patch Queue Manager approach, but it is good to understand the whole system.
| |
| − | | |
| − | ==== If anyone is allowed to push to the trunk ====
| |
| − | | |
| − | If the project is such that it's ok for every project member to just push this to the trunk, you go into the relevant target branch, in this case the trunk:
| |
| − | | |
| − | | |
| − | <pre><nowiki>
| |
| − | $ cd ../novacc
| |
| − | </nowiki></pre>
| |
| − | | |
| − | | |
| − | ...make sure it's up-to-date:
| |
| − | | |
| − | | |
| − | <pre><nowiki>
| |
| − | $ bzr pull
| |
| − | </nowiki></pre>
| |
| − | | |
| − | | |
| − | ..and merge in the changes from your branch:
| |
| − | | |
| − | | |
| − | <pre><nowiki>
| |
| − | $ bzr merge ../lp765432
| |
| − | $ bzr commit -m "Merge fix for bug #765432"
| |
| − | $ bzr push lp:novacc
| |
| − | </nowiki></pre>
| |
| − | | |
| − | | |
| − | ..and that's it.
| |
| − | | |
| − | ==== If only approved code is allowed to be pushed (honour system) ====
| |
| − | | |
| − | Usually, there will be a more formal review process. For this, Launchpad offers a concept called Merge Proposals:
| |
| − | | |
| − | On the branch page, you will see a "Propose for Merging" link. Clicking this will create a Merge Proposal for your branch, by default targetted to the development focus of the project. You can add a note about the proposal, and optionally you can add a commit message to be used for when this proposal has landed.
| |
| − | | |
| − | The Merge Proposal is where all things code-review related happen. The code review process is a conversation that can happen over email or through the web interface. Developers can vote on the proposal (approve, deny, etc) and additionally the proposal itself has statuses (Approved, Rejected, Work In Progress). When a Merge Proposal changes status is a project policy decision.
| |
| − | | |
| − | If as the result of conversation or review the branch author decides more work is needed and he will resubmit later, he can simply set the status on the Merge Proposal to "Work In Progress" which will remove it from the review queues. When he's ready for review again, he can either set the status back to "Needs Review" - or he can click the "resubmit proposal" link, which will submit a brand new proposal which contains and references the original one. This can be useful if enough work has been done that original review votes should be cast again.
| |
| − | | |
| − | Once the Merge Proposal is approved, either you or a designated "merge captain" can go ahead and do what's outlined in the "If anyone is allowed to push to the trunk" section.
| |
| − | | |
| − | ==== If the trunk is guarded by a Patch Queue Manager ====
| |
| − | | |
| − | The process here is the exact same as the only-approved-code approach above, but instead of having developers do the merge themselves or having a designated merge captain do it, you can use an automated Patch Queue Manager system such as Tarmac. In this case, a special Launchpad user is created on Launchpad for this purpose. This user owns the branch that is designated as the trunk. This way, noone can commit directly to the trunk. Tarmac will at intervals scan for approved merge proposals (see "If only approved code is allowed to be pushed (honour system)" section) and automatically merge each of them, run the unit tests, and push them to the trunk if the trunk is clean. If there is a problem with the merge, the Patch Queue Manager will report the problem as a comment on the merge proposal and reset the merge proposal status to Work In Progress.
| |
