So, you are interested in a particular piece of software from a particular upstream project. Maybe you are even part of the Upstream project yourself. Awesome! There are a number of things that help Ubuntu keep a particular package in good shape and your skills and interests are needed to make a great collaboration happen.
This page intends to list important information for members of the community who are interested in bringing Ubuntu and an upstream project closer together. It tries to give a quick overview over how things work in Ubuntu and which other pages are best to consult for more information.
Overview
If you have been involved in some conversations in the open source world, you have probably noticed that in a lot of cases it's all about releases, features, bugs, and patches. It's important to us that you, as a bridge between Ubuntu and the upstream project, help to liaise in those conversations. It should be fairly obvious that we all benefit from the sharing of:
- information about important bugs
- patches
- information about release dates, future plans, etc.
What's in the nutshell
If you are passionate about an upstream project and want to bring Ubuntu and that project closer together, you could (and probably would like to) do one or more of the following:
- keep track of what's happening in the upstream project
- triage Ubuntu bugs of that project, making sure to forward relevant and good bugs upstream
- coordinate new upstream releases and fixes with Ubuntu
- upload those releases to Ubuntu
- become an Ubuntu developer over time
- act as a bridge between the two projects
Ubuntu Development
UbuntuDevelopment is the de-facto guide about Ubuntu development and Ubuntu processes. You will notice that the sequence of events in the development cycle is really important. To better illustrate that, we put together a cheat sheet (source) for you. Also there's the glossary which contains all the acronyms you might not be familiar with yet.
Debian is one of our essential upstream projects, so it's important that you find out how we work with Debian.
- Ensure upstream is aware of Ubuntu release plans/schedule/policies. Please note that we would like upstreams to be aware, but in no way forcing them to adjust their schedule
- You should be aware of development upstream so that you are keen on how that applies to Ubuntu:
- Subscribe to upstream mailing lists
- Be available in the upstream IRC channel (If you're into IRC)
- Recognize when large changes in upstream affect Ubuntu and communicate that back to the project (ie. a major rewrite or significant changes that affect its package in Ubuntu)
Bugs
The Bug Squad put together some great documentation about how to best make use of Launchpad, how to track bugs, and how to organize Bug days. You also might want to have a look at our DebuggingProcedures to add docs which will help new triagers better debug the software and bugs you are interested in.
- It's important that we keep track of bugs in Ubuntu efficiently, make sure the problem is well-understood and can be submitted to the upstream authors in an isolated fashion (without all the noise in the bug report).
- Take ownership of bug work and collaborate with other volunteers to ensure that bugs are flowing into the upstream bug tracker (with links in Launchpad)
- Check upstream bug and patch workflow. Finding ignored/lost bugs and patches can be very useful.
- Track bugs that are fixed upstream, but NOT fixed in Ubuntu, and work on getting those fixes out to our users.
If necessary, getting the fixes in via the StableReleaseUpdates (SRU) process.
- If not, ensuring that the fix doesn't get lost the next time the package is synced from Debian.
Work with the QA team and schedule Bug Days for your specific package to help manage bug numbers.
- Keep upstream bug tracker information on bugs page up to date (or create it if needed).
You can easily subscribe to the bug mail of a package.
More information on working specifically on bugs can be found at the wiki page of the Bug Squad's Adopt-a-Package initiative.
Testing
Write Testcases for your application. (Guidelines)
Packages and Patches
To get a patch or package uploaded, you might want to check out the Sponsorship Process. Once you're more familiar with packaging, the package itself and Ubuntu development in general, you can apply for upload rights for that package and others.
Make sure you review all bugs with patches in Launchpad. The ReviewersTeam has great guidelines for doing that. For example: All Ubuntu's gedit bugs with patches attached.
- Keep track of bugs which highlight deltas with upstream changes and tag them with "upstream-delta" (To be discussed)
- Keep track of unreviewed patches from Ubuntu developers in the upstream bug tracker
Example: https://bugzilla.gnome.org/page.cgi?id=patchreport.html&product=banshee&patch-status=none
- Work with upstreams in getting testing on these patches so as to keep the delta between upstream and Ubuntu as small as possible.
- Perhaps help get the patches in a PPA build so upstream can test feedback on the fixes.
Things you should know
Things you should know
You should have decent bug triaging experience. Ideally you would be in the Ubuntu Bug Control team or eventually apply to it as a part of this role. However, if you don't have much experience you should feel comfortable participating in Bug Days to improve.
- Usually asking an upstream where they want certain types of bugs can go a long way to reduce the noise for them.
- You should have some experience with the upstream project - it really helps if you're working on something you know well.
- Remember that a positive attitude and a willingness to learn are what most people look for when working in a team, so don't be put off if you are not an expert!
- Upstreams will probably differ on how they do things. Join their IRC channel and mailing lists, lurk for a while, ask questions. In summary, try to get a feeling of how they work. It is easier for one to adjust to a group than for a group to adjust to one.
- Keep in mind that others may be trying to help on the same upstream; whenever possible, try to work as a team, presenting a coherent approach (of course, there will be differences of opinion).
If you are an upstream developer who is interested in doing this role or is doing it already you should contact JorgeCastro to get the proper Launchpad permissions to triage your own bugs. And please, be sure we will welcome you!
Use the Workspaces page for anything you might need; tracking status, noting down issues, etc.