While learning about Ubuntu development & packaging, there's one part that's not quite clear to me. So, let's say we're in the middle of active development (e.g. Raring) before feature freeze and I want to work on improving a program packaged for Ubuntu – e.g. Guake. I would like to fix a bug, add a new feature etc. Now, I see two ways of doing this:
- working on the upstream trunk lp:guake, submitting a merge proposal and requesting the package maintainer for Ubuntu to resync the package
- working on the package branch ubuntu:guake, submitting my fix there and letting the project or package maintainer worry about forwarding this fix upstream or creating a guake-ubuntu0 patched version for the package repo
Is one of these two approaches better? Does it depend on the situation (e.g. type of contribution – bug fix or a new feature; development phase) and if so, how? It would be great if someone experienced could give some more guidelines and advice on this topic.
When working in the GitHub ecosystem, it always seems very clear – everything is centered around the latest development version and all pull requests are submitted for it (at least I never bumped into anybody submitting stuff for some old version 0.7 of project X), while on Launchpad this disparity between package and upstream branches kind of confuses me. I'm not sure if it's better to run the latest Ubuntu development build and dig into the source that's available there (through apt-get source <package>) or should I just get the latest trunk code into my stable Ubuntu, make the change and see if I can somehow get maintainers to forward this change towards the package (resyncing, checking if the builds still work against other Ubuntu libraries etc.)
I read both the old and the new packaging guides, but it still left me puzzling about these questions.
Best Answer
You need to conceptually separate Ubuntu from upstream, even when the upstream branch is hosted on Launchpad. The vast majority of packages in Ubuntu have their upstream branch hosted somewhere else completely (i.e. GitHub or SourceForge). An upstream project that is hosted on Launchpad might have a closer relationship with Ubuntu, but it should be treated essentially like any other upstream project.
Ubuntu redistributes upstream software usually only making changes when necessary for integrating with all the other software we ship. In most cases, the best option is to fix bugs upstream. That way the fix reach the most people. This also reduces the burden in Ubuntu by not having to maintain the local modifications.
So ideally, the process looks like your first option. You fix the bug upstream, upstream makes a new release, and Ubuntu updates to that version. As you've noticed, things don't always work that way.
Sometimes the release schedules of Ubuntu and an upstream project might not be aligned. Say you've found and fixed a bug that you'd like to see in the next Ubuntu release, but Ubuntu is releasing in three months and upstream has no idea when its next release will be. In a situation like this, the best approach is to fix the bug upstream but backport it to the release in Ubuntu as an Ubuntu specific patch. This is also the case when making a fix in a stable release of Ubuntu where we will most likely not be able to include a new upstream release.
Sometimes Ubuntu carries changes to upstream. If the bug lies in those changes, the fix should go directly to Ubuntu. This includes issues in things like the packaging.
New features are extremely unlikely to be accepted in Ubuntu unless it has already been accepted upstream. We will often accept patches fixing a specific problem before its been applied upstream for the sake of the larger project, but we normally don't like to deviate from upstream in terms of design or functionality.
I know that I'm basically just saying it depends, but it does!