SeekingSponsorship

Differences between revisions 1 and 21 (spanning 20 versions)
Revision 1 as of 2008-10-23 15:52:04
Size: 2675
Editor: 92-236-87-214
Comment: Add some information on getting sponsorship for a branch
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 6: Line 10:
== Linking to a bug == 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.
Line 8: Line 14:
As you will need a bug report to seek sponsorship you should
close it from your '''debian/changelog'''. Fill in the changelog
entry and add the '''LP: #12345''' entry and normal.
== 1 - Linking to bugs ==
Line 12: Line 16:
Now, you can tell bzr that this commit fixes that bug in launchpad,
so when you commit use
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:
Line 16: Line 22:
$ bzr commit --fixes lp:12345 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
Line 19: Line 29:
Alternatively, from Intrepid onwards putting the bug number in the
changelog and using '''debcommit''' will do this automatically.
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.
Line 25: Line 39:
== Pushing to launchpad == 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.
Line 27: Line 42:
N.B. Launchpad does not yet offer personal source package branches. == 2 - Pushing to Launchpad ==
Line 30: 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 33: Line 48:
$ bzr push lp:~james-w/ubuntu/+trunk/seccure/fix-12345 $ bzr push lp:~james-w/ubuntu/natty/seccure/seccure-fix-12345
Line 36: Line 51:
where you change "james-w" for your launchpad username. 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 38: Line 54:
If you linked a commit to a bug number using '''--fixes''' then this If you linked a commit to a bug number using '''debcommit''' then this
Line 41: Line 57:
This however does not currently generate any bug mail. What you should
do is add a comment on the bug report stating that you have a fix
available, and subscribe the relevant sponsor team. The comment should
include a link to the branch that you pushed, using the '''lp:'''
notation so that sponsors can easily grab your fix, e.g.
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:
Line 48: Line 64:
Hi,

I think my branch fixes this bug. I changed it to frob the wotsit
so that users can twiddle the blurp. Please review it for inclusion.

You can grab my branch from

  lp:~james-w/ubuntu/+trunk/seccure/fix-12345

Thanks,

James
$ bzr lp-propose
Line 62: Line 67:
== Dealing with feedback from sponsors == 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 ==
Line 79: Line 122:
Now you can add another comment to the bug report, something like 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:
Line 82: Line 138:
Hi,

Thanks for the feedback, I have made all of the changes requested in
my branch. You can once again retrieve it from

  lp:~james-w/ubuntu/+trunk/seccure/fix-12345

Thanks,

James
$ sponsor-patch -b -B sbuild -w ~/testbuild XXXXXX
Line 94: Line 141:
Once the sponsor has uploaded your change you can delete your local
branch, and mark the branch on launchpad as merged.
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

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)