Diff for "CrossProjectBugTracking"

Not logged in - Log In / Register
Differences between revisions 2 and 3
⇤ ← Revision 2 as of 2008-06-17 14:21:16 →
Size: 4090
Editor: localhost
Comment: converted to 1.6 markup
← Revision 3 as of 2009-08-28 15:08:33 → ⇥
Size: 28
Editor: 92-237-59-186
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
The key advantage of bug tracking in Launchpad is the ability to collaborate with other communities that are experiencing the same bug.

For example:

 * if you are an upstream developer and you want to collaborate with Ubuntu or other distribution developers and users
 * if you are the developer of a piece of "middleware" such as a library, or a framework, or a scripting interpreter, which is used by other developers and where a bug could show up in THEIR project just as easily as it could in your own testing

When you look at a bug in Launchpad, you will see a table at the top of the page which lists all the different places where that bug has been reported, and where people might be working on a fix. This includes different communities, and different versions of a particular product. For example, for a serious bug in Ubuntu you might see that people are working on fixes to be published as updates to old versions as well as working in the upstream community.

== Integrating with existing bug trackers ==

Each project might have their own bug tracker. In Launchpad, you can keep track of a bug in almost any other bug tracker. Each "row" in the table of places affected by the bug can be "connected" to a bug in any instance of Bugzilla, or RoundUp, or the Sourceforge bug tracker. When you connect the row to that remote bug (we call it a "bug watch") the status will be automatically updated every couple of hours.

This means you can monitor bugs in multiple bug trackers without having an account in any of them, just connecting the bugs to Launchpad.

== Effective Collaboration Techniques ==

 * '''Passing bugs on to the distro team easily.''' If a bug is reported in your project and it is actually specific to the Ubuntu package, you can easily ask the Ubuntu developers to look into it by adding an additional row to that table. Just click on "Also affects... Distribution" below the table, and select the distribution (and source package if you know it).

 * '''Passing bugs upstream easily.''' If you are working in a distribution that uses Launchpad, and a bug is reported that is really a bug in the upstream code and not the packaging, you can easily pass the bug to the upstream developers by adding a row for the upstream project. Click on "Also affects... Upstream" and select the relevant upstream project.

 * '''Passing bugs between multiple projects.''' Imagine a developer working on a Zope application. A user reports a bug in his application, but it looks to him like a bug in Zope. He can add a row for Zope, which means this bug will show up in the Zope project bug listing. When the Zope developers look at it, they realise that it is actually a bug in Python. They can easily pass the bug to the Python developers in the same fashion. Each time this happens, the entire conversation is preserved, so someone being brought into the loop has a full sense of the discussion so far.

 * '''Finding bugs that other people have already fixed.''' On your project bugs page, you will see a count of the bugs reported in your project which are shared with other projects, where the other projects have already marked the bug as fixed. This is a very useful way to find low-hanging fruit of fixes in other distributions or upstream projects.

 * '''Tracking bugs that affect many projects.''' In some cases, a bug in one project turns out to have symptoms that show up elsewhere. For example, a security issue in libz will have consequences for many other projects which include that code directly. In such a case you can track all of those projects in a single place and see instantly which places have fixed the bug, and which have not.

 * '''Tracking backports of fixes to stable releases.''' In many cases, a serious bug needs to be fixed not only for the next version, but also in existing stable version of your software. These backports can be tracked in exactly the same place - you can see at a glance the status of fixes for a bug in the development trunk of your package or project, as well as in stable version.		 #redirect Bugs/YourProject

CrossProjectBugTracking (last edited 2009-08-28 15:08:33 by 92-237-59-186)