ImproveFixingBugs

Summary

A number of tasks that are part of fixing a bug require quite a lot of background knowledge. Luckily some of them can be automated. The "start-hacking" project will serve as a test-bed to further simplify the process.

Also will we improve the documentation about fixing bugs in Ubuntu.

Release Note

We started work on a tool collection called "start-hacking" as a test-bed to improve the bug fixing experience. Also was the documentation for fixing a bug reviewed and improved.

Rationale

If you want to get the process of "fixing a bug" right without knowing it beforehand, it's extremely hard. Partly because there's too many moving parts and parties involved, partly because the documentation is too hard to understand and follow, partly because our tools make no opinionated choices for you.

User stories

Michael wants to fix a bug in an application that he doesn't know the name of. Bugs/HowToFix recommends installing start-hacking. He starts a tool that finds the proper bzr branch for him, when he clicks on the application.

Implementation

A number of possible tools were discussed:

  • hack-on, which gives you the branch locations of an application you clicked on

  • test-build, which performs a test build of your branch for you

  • a tool that gives you more information about a certain bug number:
    • pointers to the SRU process if filed against an older Ubuntu release
    • pointers to the upstream branch history (so you can check if the issue was fixed already)
    • information on the state of the current development release (which freezes we are in already and what they mean)
    • pointers to the upstream bug tracker
    • etc.
  • a tool that automatically checks out the source for a given bug or package

In addition to that Bugs/HowToFix will be improved and streamlined and Launchpad improved so contributors can find the upstream bug tracker more easily.

The tools collection won't be ready for announce after this cycle, but we will invite Ubuntu developers to share their tools, so this can become part of an improved and simplified bug fixing process in natty+1.

BoF agenda and discussion

Steps:
======

 - Find the right package
   + jml has a script that allows you to click on a running application and it will tell you which package it is in
     lp:~jml/+junk/hack-on  [1]

 - Get the source
   + we could recommend 'debcheckout'

 - Finding the solution
   + it would be nice to have documentation that explains how to find more information about what happened upstream or in debian that probably might fix the problem
   + bug tracker database, etc. lives in Launchpad
   + https://wiki.ubuntu.com/Debian/Bugs

 - Follow the conventions
   + recommend edit-patch
   + improve documentation with necessary steps
   + recommend adding test-cases

 - Testing it
   + "bzr localbuild" could something like "apt-get build-dep <...> && bzr bd"
     https://bugs.launchpad.net/ubuntu/+source/bzr-builddeb/+bug/611525
   + localbuild could ask user if package should be installed


Additional problems:
 - problem might be in a library or module instead of the app itself
 - "bzr branch <source package branch>" should be faster
 - improve UI for finding related upstream bug tracker
 - improve looms experience
 - edit-patch lacks a non-interactive mode (bug 612566)
 - debcheckout does not check out the source for the current release you're running
 - sponsor-patch can be used for adding the patch and uploading it to a ppa (once bug #612566 is fixed)
 - it'd be nice to have a tool that turns a patch into a merge proposal
 - external service that provides information about how to fix a given bug
 - try to bridge gap between "teaching everything" and "make it really simple" by letting the user know what's going on
 - inform user upfront about stable release updates policy ("this is a fix for lucid, if it doesn't fix an urgent problem, it might only get applied in the current development release."). However you could make a PPA of it.



ACTIONS:
[deryck] look into fixing the problem of finding the upstream bug tracker more easily
[jml] add source download capabilities to "hack-on"
[jml] to create some collaborative environment "hack-on": DONE
[james-w] add test-build to "hack-on"
[dholbach] blog about "hack-on"
[dholbach] update Bugs/HowToFix and massage recommendations into it
[persia] update Bugs/HowToFix and massage recommendations into it
[pvillavi] work with dholbach and persia on Bugs/HowToFix

[1] Example output
$ ./bin/hack-on 
Source package: ubuntu/+source/emacs-snapshot
Source package branch: lp:ubuntu/emacs-snapshot

Upstream project: emacs
Upstream branch: lp:emacs

CategorySpec

Specs/ImproveFixingBugs (last edited 2010-11-08 10:54:01 by i59F72BBB)