SeekingSponsorship

Differences between revisions 9 and 21 (spanning 12 versions)
Revision 9 as of 2010-01-20 12:05:25
Size: 4032
Editor: 94
Comment:
Revision 21 as of 2013-12-03 12:24:46
Size: 5901
Editor: dholbach
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
= Obsolete =

The Packaging Guides on this wiki are no longer being actively maintained. The information here is being ported to [[http://packaging.ubuntu.com/html/|a new guide]]. You can file bugs and help to write it by visiting [[https://launchpad.net/ubuntu-packaging-guide|the guide's Launchpad project]].
Line 18: Line 22:
python-soaplib (0.0+svn44-2ubuntu1) lucid; urgency=low seccure (0.0+svn44-2ubuntu1) natty; urgency=low
Line 20: Line 24:
  * debian/control: Set XS-Python-Version for compatibility >= 2.5 (LP: #494704)   * debian/control: Set XS-Python-Version for compatibility >= 2.5 (LP: #12345)
Line 41: Line 45:
by others. You do this by pushing it to a branch under your user. by others. You do this by pushing it to a branch under your user (since you won't have permission to push it back to the original branch location):
Line 44: Line 48:
$ bzr push lp:~james-w/ubuntu/karmic/seccure/seccure-fix-12345 $ bzr push lp:~james-w/ubuntu/natty/seccure/seccure-fix-12345
Line 47: Line 51:
where you change "james-w" for your launchpad username, and "karmic" for
the release that you are targetting.
where you change "{{{james-w}}}" for your launchpad username, and "{{{natty}}}" for
the release that you are targetting. Note that the only element of the branch location that is arbitrary is the final element ("{{{seccure-fix-12345}}}"). Although it can take any value, please try to ensure that it is meaningful. See ../GettingTheSource for further details.
Line 53: Line 57:
However, this usually isn't enough to get Ubuntu developers to review your
change.  You should next propose a merge so that the developers can find your
However, pushing the branch alone usually isn't enough to get Ubuntu developers to review your
change. You should next propose a merge so that the developers can find your
Line 57: Line 61:
To do this open your page in a browser, e.g. To do this run:
Line 60: Line 64:
$ bzr lp-open $ bzr lp-propose
Line 63: Line 67:
if that fails, then you can use If that fails, then you can use
Line 66: Line 70:
$ xdg-open https://code.launchpad.net/~james-w/ubuntu/karmic/seccure/seccure-fix-12345 $ xdg-open https://code.launchpad.net/~james-w/ubuntu/natty/seccure/seccure-fix-12345
Line 71: Line 75:
an explanation of your change in the "Initial Comment" box.
Set the "Reviewer" to be either "ubuntu-main-sponsors" or
"ubuntu-universe-sponsors" depending on whether the package is
in main/restricted or universe/multiverse. Lastly click
an explanation of your change in the "Initial Comment" box. Lastly click
Line 76: Line 77:

Note that if you had to get a branch for a particular user/team (see the example on ../GettingTheSource), you will need to push to a branch named like that in the example above, but you will need to change the "target branch" when you propose to match the original branch you retrieved.
Line 86: Line 89:
}}}

Another way is to run the following command from your branch.

{{{
$ bzr diff -r-2..-1 > ../my-super-awesome.debdiff
Line 120: Line 129:
== 5 Try your patch out with sponsor-patch ==

Some sponsors use the tool ''sponsor-patch'' from the package ''ubuntu-dev-tools'' to streamline the sponsorship process. Once you've requested sponsorship, try this out too, you might find some issues before a sponsor spends their time on it.

First thing you should do is setup pbuilder or sbuild for testing your package build in a clean environment. Its highly recommended to set one of these up and try out builds using them before you even request sponsorship, as it will help you to avoid basic mistakes like missing build dependencies.

Once you have one of these run either:

{{{
$ sponsor-patch -b -B sbuild -w ~/testbuild XXXXXX
}}}

or

{{{
$ sponsor-patch -b -B pbuilder -w ~/testbuild XXXXXX
}}}

Where XXXXXX is the bug report ID you are trying to close.

This should download your patch, the orig file, and test the build in a clean environment, in almost the same exact way that a sponsor would do it.

Obsolete

The Packaging Guides on this wiki are no longer being actively maintained. The information here is being ported to a new guide. You can file bugs and help to write it by visiting the guide's Launchpad project.

Seeking Sponsorship

If you have made a change to the package and you do not have rights to upload the package then you will need to seek a sponsor.

Note that most sponsorship is still done via debdiffs, and some sponsors will prefer that, so you may wish to attach a diff to the bug as well.

1 - Linking to bugs

You will need a bug report to seek sponsorship you should close this issue from your debian/changelog. Fill in the changelog entry by running dch -i and add the LP: #12345 entry as normal. For example:

seccure (0.0+svn44-2ubuntu1) natty; urgency=low

  * debian/control: Set XS-Python-Version for compatibility >= 2.5 (LP: #12345)

 -- Barry Warsaw <barry@canonical.com>  Mon, 04 Jan 2010 15:33:52 -0500

As of Intrepid, the best way to commit this is to put the bug number in the changelog, and use debcommit. This will issue the correct bzr command, linking it to the Launchpad bug you've specified. Make sure to use text of the form "LP: #12345, #12346"; if you leave out the space or the # then debcommit will not detect it. You can use debcommit -n to check what it's going to do.

Now, when you push the branch to launchpad it will link the branch and the bug report.

It is not critical to have a link to a bug for every change you make, but if you are fixing reported bugs then linking to them will be useful.

2 - Pushing to Launchpad

Now you should push the branch to launchpad so that it can be retrieved by others. You do this by pushing it to a branch under your user (since you won't have permission to push it back to the original branch location):

$ bzr push lp:~james-w/ubuntu/natty/seccure/seccure-fix-12345

where you change "james-w" for your launchpad username, and "natty" for the release that you are targetting. Note that the only element of the branch location that is arbitrary is the final element ("seccure-fix-12345"). Although it can take any value, please try to ensure that it is meaningful. See ../GettingTheSource for further details.

If you linked a commit to a bug number using debcommit then this will show up on the bug page as having a possible fix for the bug.

However, pushing the branch alone usually isn't enough to get Ubuntu developers to review your change. You should next propose a merge so that the developers can find your fix and review it.

To do this run:

$ bzr lp-propose

If that fails, then you can use

$ xdg-open https://code.launchpad.net/~james-w/ubuntu/natty/seccure/seccure-fix-12345

where most of the URL matches what you used for "push". Then you can use the link "Propose for merging into another branch", and then type in an explanation of your change in the "Initial Comment" box. Lastly click "Propose Merge" in order to complete the process.

Note that if you had to get a branch for a particular user/team (see the example on ../GettingTheSource), you will need to push to a branch named like that in the example above, but you will need to change the "target branch" when you propose to match the original branch you retrieved.

3 - Generating a debdiff

As noted in the beginning most of the sponsors still prefer sponsoring debdiff attached to bug reports.

One way is to run the following command from your branch.

$ bzr diff -rbranch:../seccure

Another way is to run the following command from your branch.

$ bzr diff -r-2..-1 > ../my-super-awesome.debdiff

Another way is to is to open the merge proposal and download the diff.

You should ensure that diff has the changes you expect, no more and no less.

Name the diff appropriately e.g. seccure-fix-12345.debdiff and attach it to the bug report.

4 - Dealing with feedback from sponsors

If a sponsor reviews your change and asks you to change something then you can do this fairly easily. Simply go to the branch that you were working in before and make the changes requested, and then commit.

$ bzr commit

Now you can push your changes up to launchpad as before, but bzr will have remembered where you pushed to, so you can simply run

$ bzr push

Then you can reply to the request for changes explaining what you changed and asking for re-review, or reply on the merge proposal page in Launchpad.

Note if you are sponsored via debdiff attached to a bug report you need to manually update it as described in step 3.

5 Try your patch out with sponsor-patch

Some sponsors use the tool sponsor-patch from the package ubuntu-dev-tools to streamline the sponsorship process. Once you've requested sponsorship, try this out too, you might find some issues before a sponsor spends their time on it.

First thing you should do is setup pbuilder or sbuild for testing your package build in a clean environment. Its highly recommended to set one of these up and try out builds using them before you even request sponsorship, as it will help you to avoid basic mistakes like missing build dependencies.

Once you have one of these run either:

$ sponsor-patch -b -B sbuild -w ~/testbuild XXXXXX

or

$ sponsor-patch -b -B pbuilder -w ~/testbuild XXXXXX

Where XXXXXX is the bug report ID you are trying to close.

This should download your patch, the orig file, and test the build in a clean environment, in almost the same exact way that a sponsor would do it.


CategoryDistributedDevelopment

DistributedDevelopment/Documentation/SeekingSponsorship (last edited 2013-12-03 12:24:46 by dholbach)