So a while back I reported a bug in Compiz's Place Window plugin. It's a fairly major regression for people affected by it: mainly those using Gnome-Fallback, judging by the reports.
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 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.
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.
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.
It would require a Stable Release Update to ship it to 12.04. See https://wiki.ubuntu.com/StableReleaseUpdates for acceptable types of fixes, and procedure for getting them in.
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:
ubuntu-srushould be subscribed to the bug report.
-proposedIn 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.
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.
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:
Here's an explanation of the impact of the bug on users and a justification for backporting the fix to the stable release
Here's a discussion of any potential for regressions.
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:
$ pull-lp-source compiz precise $ wget https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/974242/+attachment/3141645/+files/fix-974242.patch
Now we'll add the patch to the source package:
$ cd compiz-0.9.7.8/ $ add-patch ../fix-974242.patch
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:
compiz (1:0.9.7.8-0ubuntu1.1) precise-proposed; urgency=low * debian/patches/fix-974242.patch: [DESCRIBE CHANGES HERE] -- Your Name <email@example.com> Mon, 11 Jun 2012 17:37:59 -0400
The file at
debian/patches/fix-974242.patch also has some headers that you might want to edit:
## Description: add some description ## Origin/Author: add some origin or author ## Bug: bug URL
Now build your new source package:
$ debuild -S -us
And create the debdiff:
$ cd .. $ debdiff compiz_0.9.7.8-0ubuntu1.dsc compiz_0.9.7.8-0ubuntu1.1.dsc > sru-for-lp-974242.debdiff
You can now attach the resulting
debdiff file to your bug report.