A patch surfaced a short time later. I created a PPA for testing and everybody involved so far is reporting the issues are fixed. It even fixes another bug. I've done testing with a standard Unity desktop and can say (for my testing) no adverse effects were visible.

I want to get this pushed to Ubuntu right now for two main reasons:

I'm selfish. I don't want to need to update my PPA every time a new version of Compiz is pushed to 12.04.

I don't want Ubuntu users seeing their windows flying around because of a silly little bug.

I want this patch pushed to Ubuntu's version of Compiz as soon as possible, so we can mark these bugs fixed and move on with our lives.

Whose leg do I have to hump to get this pulled into Ubuntu right now?

I don't maintain this project and it's an upstream thing but it's fairly integral to Ubuntu. I could go to Compiz but I imagine that if they accept the patch, it'll be months (at least a release) before it's anywhere near Ubuntu.

And when I do find the right person, how can I make the process as slick as possible for them?

I want them to see my request, go "Yup, that all looks great, done" and that be it. I don't want seventeen rounds of emails addressing aspects of the patch. More importantly, I don't want to waste their time either.

And what do I have to provide them? My packaging skills are... lamentable. This was my first attempt at patching a package for redistribution so I've probably made every single packaging error known to man. Will they be happy with the original patch (so they can apply it themselves) or should I repackage things so the diff/changelog is a little cleaner (it took me a few goes and the versioning is all over the place).

Note: This question is about Compiz but I'd prefer if answers could address other styles of package too so we have an authoritative and comprehensive thread of how to get things fixed.

2 Answers
2

As Dobey mentioned, in order for a patch to be accepted into an already released version of Ubuntu, it must got through the Stable Release Update (SRU) process. The bar to entry for SRUs is quite high. A simple way to sum up the thinking behind the process might be: "The bug we know is better than the bug we don't know about." In practice, that means that only targeted bug fixes are allow and no changes that are too "intrusive."

There are a number of requirements that must be met in order to proceed with an SRU:

The bug is fixed in the current development release (i.e. quantal).

The bug report's description must be updated to include a justification for why the fix is needed in the stable release, a test case to reproduce the bug and verify it has been fixed, and a discussion of the fix's regression potential.

The Launchpad team ubuntu-sru should be subscribed to the bug report.

The package is then uploaded to release-proposed In order for this to happen, you will need to go through the sponsorship process (more info below).

After all that has occurred, the SRU team will verify that the package in -proposed resolves the bug. Then the package will be pushed into -updates after it passed a minimum aging period of 7 days.

Finding the right person

Your question hints at the fact that sometimes Launchpad seems like it is where patches go to die. Sadly, if you don't know the process it can feel like that, but I swear it's not really that bad. Luckily, the main thing you need to know is simple. Check out the sponsorship process for all the details and some hints, but the most important part is to subscribe the ubuntu-sponsors team to the bug report. That ensures that it will show up in the sponsorship queue and get looked at by an honest to god Ubuntu developer.

If you need to talk something over in real time, #ubuntu-devel on Freenode IRC will do the trick. Check the channel topic for the current patch pilot. They're there to help you. If there's no pilot on duty, feel free to ask for help in the channel, but please be patient.

Getting everything ready to go

In order to make the process go as quickly as possible there are a few things to do.

Update the bug description to look like:

[Impact]

Here's an explanation of the impact of the bug on users and a
justification for backporting the fix to the stable release

[Test Case]

Step

By

Step

Instructions

To Verify

The Fix

[Regression Potential]

Here's a discussion of any potential for
regressions.

[Original Report]

Every thing that used to be in the description is
retained below.

Next, prepare your patches. Things will go much quicker if you provide debdiffs that take care of all the packaging bits rather than a patch against the upstream source. This includes using the packages patch system if it uses one. Luckily add-patch from ubuntu-dev-tools can take care of that for you.

Let's walk through this. First grab the source and the patch in the bug report:

This will add the patch to debian/patches and run dch prompting you to add a new entry to debian/changelog Adjust the entry to target proposed and increment the version number so that it will be below the next version uploaded to the development release. Like so:

excellent answer, good stuff. You may wish to note that at least as far as 12.04/12.10 the command is pull-lp-source. Don't have any earlier to see if/when it was pull-launchpad-source
–
dougJul 23 '12 at 3:30