Differences
This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
agasti:developer:launchpad_code_submission [2011/03/25 22:37] cheuschober |
agasti:developer:launchpad_code_submission [2011/03/26 19:02] (current) |
||
---|---|---|---|
Line 5: | Line 5: | ||
This guide assumes you have already discovered how to [[agasti: | This guide assumes you have already discovered how to [[agasti: | ||
- | ===== Step 1: Merge in Updates from the Parent | + | ===== Step 1: Prepare for a Merge ===== |
The first step on the road to code submission is getting your branch back up to speed. | The first step on the road to code submission is getting your branch back up to speed. | ||
Line 22: | Line 22: | ||
</ | </ | ||
- | === Merge from Parent === | + | ===== Step 2: Merge from Parent |
Now that you've committed, you can merge in changes from your parent branch. Do you see above, how I created this branch from lp: | Now that you've committed, you can merge in changes from your parent branch. Do you see above, how I created this branch from lp: | ||
+ | |||
+ | <code bash> | ||
+ | bzr merge lp: | ||
+ | </ | ||
=== Deal with Conflicts (Eeep!) === | === Deal with Conflicts (Eeep!) === | ||
Line 35: | Line 39: | ||
Oh, and while you're at it, we wholly recommend using [[http:// | Oh, and while you're at it, we wholly recommend using [[http:// | ||
+ | |||
+ | Once you've fixed the conflicted files, you can officially resolve the conflict by issuing the following. | ||
<code bash> | <code bash> | ||
Line 52: | Line 58: | ||
===== Step 3: Verify your Patches Still Work! ===== | ===== Step 3: Verify your Patches Still Work! ===== | ||
+ | Now that you've merged in changes from the parent branch, it's best to take a little time to make sure your patches still work. You should: | ||
+ | |||
+ | * Read the log of changes from the merge | ||
+ | * Re-run any tests you have written to verify they still pass | ||
+ | * Perform functional tests whether by automation or manually | ||
+ | * Try a clean build or install with your patches applied | ||
+ | * Visually confirm that everything still works | ||
+ | |||
+ | If anything is broken, you'll need to fix the issues and start all this process again back at [[agasti: | ||
===== Step 4: Do a Documentation Sweep ===== | ===== Step 4: Do a Documentation Sweep ===== | ||
+ | Okay time to submit... right? Whoah! One second there partner! We need you to do just one more thing. Please check that you've sufficiently documented your code! Remember that this is a volunteer project and our volunteers branch maintainers have to read everything you submit before they can merge it into the trunk. Please take a moment to make sure your code is documented enough that a complete stranger can understand what's going on and that it will work with our Doxygen service. | ||
===== Step 5: Generate a Merge Directive ===== | ===== Step 5: Generate a Merge Directive ===== | ||
+ | * Code? Written! | ||
+ | * Changes? Merged! | ||
+ | * Conflicts: Resolved! | ||
+ | * Documentation: | ||
+ | |||
+ | Well, then, it sounds like you're ready to generate your merge directive! | ||
+ | |||
+ | Bzr offers us many ways to generate merge directives and Launchpad even offers a few more beyond that. To keep things simple, however, the Agasti project branch maintainers request that you generate merge directive files (which are really just very special diff packages). These are easy to generate using the bzr tools, and are portable enough to be attached to bugs, emails and many other forms of communication. | ||
+ | |||
+ | To generate your merge directive, simply execute the command below from your project directory. | ||
+ | |||
+ | <code bash> | ||
+ | bzr send lp: | ||
+ | </ | ||
+ | |||
+ | In our case above, we start by pointing our merge directive back to its parent branch; this is so bzr can know what to diff against. Our send message should tell the branch maintainers what you introduced that was new and what base revision you merged from in the parent. The last file, / | ||
===== Step 6: Create a Bug Report and Add your Directive ===== | ===== Step 6: Create a Bug Report and Add your Directive ===== | ||
+ | Now, you're ready to share your changes with the world! Open your favorite browser and go to our [[https:// | ||
+ | |||
+ | At the bottom of the bug report you can then attach a patch file by clicking //extra options//. Use this opportunity to attach the diff file you just created in the last step. Once you've sufficiently documented your changes and attached your patch, submit your bug report and move to the next (and final) step. | ||
+ | |||
+ | {{: | ||
===== Step 7: Be Patient, but Be Active! ===== | ===== Step 7: Be Patient, but Be Active! ===== | ||
- | This is perhaps the easiest step of the whole process. After you submit a merge request via your merge directive, please stick around! Hang out on IRC with us on IRC or by e-mail and be ready to answer questions about your directive. If you've created a module, pay attention to any security alerts that may arise around your new submission. It's very difficult for maintainers to justify merging code from someone who's unwilling to discuss it. | + | This is perhaps the easiest step of the whole process. After you submit a merge request via your merge directive, please stick around! Hang out with us on IRC or by e-mail and be ready to answer questions about your directive. If you've created a module, pay attention to any security alerts that may arise around your new submission. It's very difficult for maintainers to justify merging code from someone who's unwilling to discuss it. |
We also ask that you please be patient regarding your submission. We have some very smart maintainers, | We also ask that you please be patient regarding your submission. We have some very smart maintainers, |