Contact information


Project Name

Bug Triaging Improvements for Launchpad/Arsenal

Project Description

The features mentioned below were originally part of the Arsenal bug auto-triaging tools proposal. However, a useful implementation of some of these features requires modifications in the Launchpad API. Similarly, some of the features retain their usability in the web-interface as well. For these reasons, the title of this proposal was changed to reflect the fact that the will not just be limited to Arsenal.

Currently, there is no easy way of searching through a project's bug attachments because of the following reasons:

  • The REST API does not expose a bug collection for a project.

  • For a particular bug, an Arsenal search through the attachments requires downloading each attachment locally and then searching through it.

The solution would be to:

  • Create bug collection attribute for projects, e.g.:

   1 class IProduct(...):
   2     ...
   3     bugs = exported(
   4         CollectionField(
   5             title=_("List of bugs for this project."),
   6             value_type=Reference(schema=IBug),
   7             readonly=True))
  • Create bug_attachment collection search methods for bugs, e.g.:

   1 class IBug(...):
   2     ....
   3     @operation_parameters(
   4         text=TextLine(title=_("Search text"), default=u""))
   5     @operation_returns_collection_of(IBugAttachment)
   6     @export_read_operation()
   7     def findAttachments(text=""):
   8     """Return all attachments which contain <text>."""
  • Create a command-line attachment grepper.
  • Create a graphical helper for searching using pygtkmozembed.

Automatic Upstreamer

Add the functionality to forward a bug along with attachments to a remote tracker. General summary of the approach:

  • Collect bug information in an ArsenalBug instance.

  • Use Bugzilla::Webservice::Bug over the XML-RPC interface to create a remote bug and upload attachments.

Bug Matchmaker

For a given Bugzilla bug, add the functionality to search the remote tracker. However, depending solely on a web-service API or parsing HTML pages will again bring in the issue of 'one trip for each item' for the search. Therefore:

  • Launchpad plugin for Bugzilla will be used to help with the searches remotely.
  • If the user has opted to search for private bugs, use authentication procedures.

Automatic Patcher

For a given bug, generate an automatically patched package from an attachment. The procedure would be to:

  • Download the Deb/Tar package
  • For Deb, unpack and use the dpatch rules to generate a patched version

  • For Tar, unpack and patch the source code.
  • Report any errors which have occurred during the process.

The functionality will be built directly in Arsenal.

If you would be willing and able to do other projects instead, which ones?

I shall be focusing only on these improvements. They will require lot of polish and testing to reach a level of productivity where compatibility issues among the API's will not hinder the bug triaging process. Therefore, I will not be spending time on other projects during the summer.

Why did you like this idea?


  • I love Python.
  • I like playing with web service API's to create interesting interoperating applications.

Please describe a tentative project architecture or an approach to it

  • Launchpad core shall be modified to include functionality for bug attachment searching.
  • Launchpad web interface and the Bugzilla plugin shall be modified to expose attachment searching, automatic upstreaming and matchmaking.
  • Launchpad's REST API and launchpadlib shall be modified to expose attachment searching.

  • Arsenal shall be modified to include the ability of searching for attachments and automatically creating patched packages.

Give us details about the milestones for this project

  • Before June: Get up to speed with Launchpad core development process, bond with the community.
  • Second week of June: Implement attachment searching.
  • End of June: Update Arsenal to use attachment searching.
  • First week of July: Implement automatic upstreaming.
  • Second week of July: Implement matchmaking.
  • Third week of July: Modify Arsenal to generate automatically patches packages.
  • End of July: Test the changes extensively, merge into main branches.

Why will your proposal benefit Ubuntu?

  • It will help ordinary users easily report back more bug information to Launchpad.
  • It will increase the cohesion among different project's bug tracking processes. Considerable time is currently wasted because of lack of interoperability among upstream trackers and Launchpad.
  • It will greatly speed up the bug triaging process for maintainers and developers.

Open Source

Please describe any previous Open Source development experience

Why are you interested in Open Source?

Because trusting closed source is akin to having an unpublished and unreviewed block cipher as the AES.


How long will the project take? When can you begin?

The project should take around two months for releasing the features in a production-ready state. I can begin after May 19, i.e., after my current semester ends.

How much time do you expect to dedicate to this project? (weekly)

Around 7-8 hours per day for 4-5 days each week.

Where will you based during the summer?

Islamabad, Pakistan.

Do you have any commitments for the summer? (holidays/work/summer courses)

I have 37 movies — and 2 seasons of Flying Circus pending — on my wishlist, that's about it.

Please designate a back up student (in case you need to withdraw your application)

I don't personally know anyone interested in Launchpad development so any designation would be a random guess at best.


Have you ever participated in a previous GSoC? (describe your project)


Have you applied for any other 2010 Summer of Code projects? If yes, which ones?

Going to apply for the LSB project of cross-distribution dependency translation tool.

Why did you apply for the Google Summer of Code ?

  • Getting paid for working on something I love is too good an idea to pass.
  • In my country there aren't (m)any opportunities for paid open-source work. So I'd prefer spending the summer in my room working on Launchpad instead of at a company working with crippled Java written by someone else.

Why did you choose Ubuntu as a mentoring organisation?

Because I have worked with Launchpad before and I use it for managing all of my tiny open-source utilities. My project is essentially concerned with Launchpad and Ubuntu is the organization associated with it.

Why do you want to participate and why should Ubuntu choose you?

I want to participate in order to have some productive fun during the summers and contribute to the open-source world. Ubuntu should choose me because I have a great deal of enthusiasm for working on Launchpad with some open-source experience already at my hands. I have a fair amount of experience with Python, GTK+, C/C++, PHP and x86 in particular; and POSIX, open-source and web development in general.

GSoC/2010/KamranKhan (last edited 2010-04-09 17:33:52 by mbl-65-148-129)