SeekingSponsorship

Differences between revisions 17 and 18
Revision 17 as of 2011-03-10 18:06:14
Size: 5585
Editor: 89
Comment:
Revision 18 as of 2011-05-20 14:46:52
Size: 0
Editor: mail
Comment: http://people.canonical.com/~dholbach/packaging-guide/html/index.html
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
= 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)