Adopt

Differences between revisions 10 and 11
Revision 10 as of 2010-07-20 23:57:11
Size: 7522
Editor: drumperson
Comment: Fixed a typo
Revision 11 as of 2010-07-21 00:29:27
Size: 7581
Editor: drumperson
Comment: Simplified language, fixed typos, general proofreading (article could still use a rewrite with better formatting, sections, etc. Also some of the writing's a bit ambigous - could do to be cleaned up)
Deletions are marked like this. Additions are marked like this.
Line 4: Line 4:
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 it depends on your skills and your interests to make a great collaboration happen. 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.
Line 9: Line 9:
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: 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:
Line 11: Line 11:
We share
Line 17: Line 16:
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: 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:
Line 19: Line 19:
 * triage Ubuntu bugs of that project, forward relevant and good bugs upstream  * triage Ubuntu bugs of that project, making sure to forward relevant and good bugs upstream
Line 23: Line 23:
 * act as a bridge between the two projects.  * act as a bridge between the two projects
Line 26: Line 26:
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 [[http://people.canonical.com/~dholbach/cheatsheet.pdf|cheat sheet]] ([[http://people.canonical.com/~dholbach/cheatsheet.odt|source]]) for you. Also there's the '''[[UbuntuWeeklyNewsletter/glossary|glossary]]''' for all the acronyms you might not be familiar with yet. 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 [[http://people.canonical.com/~dholbach/cheatsheet.pdf|cheat sheet]] ([[http://people.canonical.com/~dholbach/cheatsheet.odt|source]]) for you. Also there's the '''[[UbuntuWeeklyNewsletter/glossary|glossary]]''' which contains all the acronyms you might not be familiar with yet.
Line 28: Line 28:
Debian is one of our essential upstream projects, so it's important you find out how [[Debian/ForUbuntuDevelopers|we work with Debian]]. Debian is one of our essential upstream projects, so it's important that you find out how [[Debian/ForUbuntuDevelopers|we work with Debian]].
Line 30: Line 30:
 * 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.  * 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
Line 34: Line 34:
  * 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)   * 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)
Line 37: Line 37:
The [[BugSquad|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 [[BugSquad|Bug Squad]] put together some great documentation about how to best make use of Launchpad, how to track bugs, and how to organize [[UbuntuBugDay|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.
Line 39: Line 39:
 * 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.
 * 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.
Line 45: Line 45:
 * Work with [[https://wiki.ubuntu.com/QATeam|QA team]] and schedule [[https://wiki.ubuntu.com/UbuntuBugDay/|Bug Days]] for your specific package to manage the bug numbers.  * Work with the [[https://wiki.ubuntu.com/QATeam|QA team]] and schedule [[https://wiki.ubuntu.com/UbuntuBugDay/|Bug Days]] for your specific package to help manage bug numbers.
Line 47: Line 47:
 * You can easily [[https://help.launchpad.net/Bugs/Subscriptions#subscribe-bugmail|subscribe]] to bug mail of a package.  * You can easily [[https://help.launchpad.net/Bugs/Subscriptions#subscribe-bugmail|subscribe]] to the bug mail of a package.
Line 49: Line 49:
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. More information on working specifically on bugs can be found at the wiki page of the Bug Squad's [[BugSquad/AdoptPackage|Adopt-a-Package]] initiative.
Line 59: Line 59:
  * Perhaps help get the patches in a PPA build so upstream can get testing feedback on the fixes.   * Perhaps help get the patches in a PPA build so upstream can test feedback on the fixes.
Line 63: Line 63:
 * You should have decent bug triaging experience, ideally you would be in the [[https://wiki.ubuntu.com/UbuntuBugControl|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 [[https://wiki.ubuntu.com/UbuntuBugDays|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.
 * You should have decent bug triaging experience. Ideally you would be in the [[https://wiki.ubuntu.com/UbuntuBugControl|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 [[https://wiki.ubuntu.com/UbuntuBugDays|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.
Line 67: Line 67:
 * 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.  * 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.
Line 69: Line 69:
 * 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!  * 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!

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.

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.

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.


CategoryUpstream

Upstream/Adopt (last edited 2010-08-18 13:59:47 by c-76-112-209-61)