Diff for "PatchSubmission"

Not logged in - Log In / Register

Differences between revisions 1 and 15 (spanning 14 versions)
Revision 1 as of 2009-08-03 22:06:48
Size: 19
Editor: kfogel
Comment: Redirect to Patches.
Revision 15 as of 2016-01-21 12:10:12
Size: 3363
Editor: cjwatson
Comment: fix push syntax
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
#redirect Patches ## page was renamed from Patches
#format wiki
#language en
#pragma section-numbers off

||<tablestyle="width: 100%;" colspan=3 style="background: #2a2929; font-weight: bold; color: #f6bc05;">This page tells you how to contribute code changes to Launchpad. [[Help|Ask for help]] right away if you run into problems. ||

= Submitting a Patch to Launchpad =

Below we describe the process of getting a code change into Launchpad. You should already [[Getting|have the Launchpad sources]], be able to [[Running|build and run]] Launchpad, and be familiar with the [[StyleGuides|coding style guidelines]].

''Note that by '''''"patch"''''', we just mean a code change, not an actual patch file meant for the [[http://en.wikipedia.org/wiki/Patch_(Unix)|patch]] program. In Launchpad, patches are typically delivered as [[http://bazaar-vcs.org/|Bazaar]] branches hosted on Launchpad itself; see below for details.''

 1. Before making your change, you need to talk about it first to a Launchpad developer. The easiest way there is to ask the person listed as the on-call reviewer (OCR) in the [[irc://irc.freenode.net/launchpad-dev|#launchpad-dev]] IRC channel on `irc.freenode.net`. That "pre-implementation chat" will make sure that you have all things covered. If your proposal involves UI changes, you might even want to make screenshots or a [[ScreenCasts|screencast]].
 1. Make sure your change is about one single thing (say, a specific bugfix), and that all the revisions for it are committed on your Bazaar branch.
 1. Push the branch up to your Launchpad user account. Run this with your local copy of the branch as your current directory: '''{{{bzr push lp:~my_username/launchpad/bugfix123}}}'''
 1. [[Testing|Run tests]] on your branch. If the tests don't pass, go back to hacking, commit new changes, re-push, and re-test. Repeat until the branch passes.
 1. Please send in your [[ContributorAgreement|contributor agreement form]] now (it's an easy email process). We can't accept the change without a contributor agreement.
 1. Propose your branch for merging, by going to https://code.launchpad.net/~my_username/launchpad/bugfix123 and click on '''Propose for merging into another branch'''. (The branch to merge into is `lp:~launchpad-pqm/launchpad/devel`.) Fill in the field for requested reviewer with the name of the reviewer you found, and follow the guidelines for writing the [[CoverLetters|merge cover letter]].
 1. If there's a bug report for your branch, make sure the bug is linked to the branch. If there isn't, file a bug, and link that to the branch.
 1. Find someone to review the branch. Usually, this would be the Launchpad developer with whom you had your "pre-implementation" chat about the change. If he or she is not available, you can ping the on-call reviewer in [[irc://irc.freenode.net/launchpad-dev|#launchpad-dev]]. See the [[Reviews|Code Review]] page.
 1. Once the reviewer approves the change, they'll take care of [[LandingChanges|merging your changes]] (that's until we work out an automated process).
 1. Once the branch lands and is deployed to qastaging (XXX - how do you find out if this is the case? do you receive an email? - jml), test the change on qastaging, verifying that the change works as expected and doesn't introduce any regressions. See [[PolicyAndProcess/QAProcess]].

This page tells you how to contribute code changes to Launchpad. Ask for help right away if you run into problems.

Submitting a Patch to Launchpad

Below we describe the process of getting a code change into Launchpad. You should already have the Launchpad sources, be able to build and run Launchpad, and be familiar with the coding style guidelines.

Note that by "patch", we just mean a code change, not an actual patch file meant for the patch program. In Launchpad, patches are typically delivered as Bazaar branches hosted on Launchpad itself; see below for details.

  1. Before making your change, you need to talk about it first to a Launchpad developer. The easiest way there is to ask the person listed as the on-call reviewer (OCR) in the #launchpad-dev IRC channel on irc.freenode.net. That "pre-implementation chat" will make sure that you have all things covered. If your proposal involves UI changes, you might even want to make screenshots or a screencast.

  2. Make sure your change is about one single thing (say, a specific bugfix), and that all the revisions for it are committed on your Bazaar branch.
  3. Push the branch up to your Launchpad user account. Run this with your local copy of the branch as your current directory: bzr push lp:~my_username/launchpad/bugfix123

  4. Run tests on your branch. If the tests don't pass, go back to hacking, commit new changes, re-push, and re-test. Repeat until the branch passes.

  5. Please send in your contributor agreement form now (it's an easy email process). We can't accept the change without a contributor agreement.

  6. Propose your branch for merging, by going to https://code.launchpad.net/~my_username/launchpad/bugfix123 and click on Propose for merging into another branch. (The branch to merge into is lp:~launchpad-pqm/launchpad/devel.) Fill in the field for requested reviewer with the name of the reviewer you found, and follow the guidelines for writing the merge cover letter.

  7. If there's a bug report for your branch, make sure the bug is linked to the branch. If there isn't, file a bug, and link that to the branch.
  8. Find someone to review the branch. Usually, this would be the Launchpad developer with whom you had your "pre-implementation" chat about the change. If he or she is not available, you can ping the on-call reviewer in #launchpad-dev. See the Code Review page.

  9. Once the reviewer approves the change, they'll take care of merging your changes (that's until we work out an automated process).

  10. Once the branch lands and is deployed to qastaging (XXX - how do you find out if this is the case? do you receive an email? - jml), test the change on qastaging, verifying that the change works as expected and doesn't introduce any regressions. See PolicyAndProcess/QAProcess.

PatchSubmission (last edited 2021-07-27 16:57:44 by cjwatson)