Added a reference to [[BugSquad/AdoptPackage]] in [[#Bugs]] and made Bug Squad link to [[BugSquad]]
|Deletions are marked like this.||Additions are marked like this.|
|Line 37:||Line 37:|
|The [[Bugs|Bug Squad]] put together some great documentation about how to best make use of Launchpad, how to track bugs and how to organise [[UbuntuBugDay|Bug days]]. You also might want to have a look at our DebuggingProcedures to add docs to help out new triagers to better debug the software and bugs you are interested in.||The [[BugsSquad|Bug Squad]] put together some great documentation about how to best make use of Launchpad, how to track bugs and how to organise [[UbuntuBugDay|Bug days]]. You also might want to have a look at our DebuggingProcedures to add docs to help out new triagers to better debug the software and bugs you are interested in.|
|Line 47:||Line 47:|
| * You can easily [[https://help.launchpad.net/Bugs/Subscriptions#subscribe-bugmail|subscribe]] to bug mail of a package.
More information of working specifically on bugs can be found on the wiki page of the Bug Squad's [[BugSquad/AdoptPackage|Adopt-a-Package]] initiative.
|Line 61:||Line 64:|
|* You should have some experience with the upstream project, it doesn't help if you're working on something you barely know.||* You should have some experience with the upstream project, it really helps if you're working on something you know well.|
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 is a number of things that help Ubuntu to have this particular package in good shape and it depends on your skills and your interests 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 best to consult for more information.
If you have been involved in some of the conversations in open source, you have 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 the Ubuntu and upstream project help to liaise in those conversations. It should be fairly obvious that we all benefit from the following:
- information about important bugs
- information about release dates, future plans, etc.
What's in the nutshell
If you are passionate about some 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, 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.
UbuntuDevelopment is the de-facto guide about Ubuntu development and Ubuntu processes. You will notice that what happens at which time in the cycle is really important. To better illustrate that, we put together a cheat sheet (source) for you. Also there's the glossary for all the acronyms you might not be familiar with yet.
Debian is one of our essential upstream projects, so it's important 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 it's package in Ubuntu)
The Bug Squad put together some great documentation about how to best make use of Launchpad, how to track bugs and how to organise Bug days. You also might want to have a look at our DebuggingProcedures to add docs to help out new triagers to 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 in an isolated fashion (without all the noise in the bug) submitted to the upstream authors.
- Take ownership of bug work and work 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 QA team and schedule Bug Days for your specific package to manage the bug numbers.
- Keep upstream bug tracker information on bugs page up to date (or create it if needed).
You can easily subscribe to bug mail of a package.
More information of working specifically on bugs can be found on the wiki page of the Bug Squad's Adopt-a-Package initiative.
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.
- 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
- 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 get testing 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 group 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 classes 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 on 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 welcome you!
Use the Workspaces page for anything you might need; tracking status, noting down issues, etc.