[IPython-dev] Bug handling: launchpad, github, other?

[Robert Kern]

On 2010-04-15 16:45 PM, Fernando Perez wrote:
> Hi all,
>
> We've been fairly diligent about using the LP tracker and I actually
> don't mind it too much (it's slow, but I got used to opening many tabs
> in parallel so each tab does its thing while I work on the others).
> The point is that we do have very valuable information there, which
> we're not going to ignore.
>
> But as we change from bzr to git for hosting, what to do with bugs
> merits an informed decision. In my mind the options moving forward
> are:
>
> 1. Stay with launchpad for bug handling, just start pointing to github
> urls instead of internal LP ones.
>
>    + less work to do.
>    - no integration with the source control system
>    - the interface is slow and a bit clunky (Brian has mentioned here
> how it drives him mad)

It drives me mad, too.

> 2. Move to github for bugs.
>
>    + good integration with the source control, e.g. bugs can be closed
> from commit messages.
>    - We'd have to link LP bugs for a while, so the existing ones can be
> tracked until completion.
>
>    - **The big negative one in my mind**  I'm not convinced the 'tags
> only' approach is a good idea:
>
> Github only offers labels for bugs, so all other information
> (ownership, category, status, etc) has to be created via labels.
> Effectively every project ends up making up a syntax for how to track
> bugs.  While I think that approach is OK for something like email, I
> think bug management is a well-defined enough problem that *some*
> generic key/value pairs should exist.  That is, bug management is a
> problem for which we know a basic model, and by not offering *any*
> model, a labels-only system forces everyone to re-invent a known
> wheel.  By having a common model, the user interface can offer
> efficient access to certain information, like all tickets targeted to
> a milestone, or open and owned by someone, etc. These have to be
> manually re-created as label-based queries for every project, and
> every single time you want them even for one project.

Another option would be to use Google Code's issue tracker. While it is sort of 
label-based, that's mostly just an illusion of the data entry UI. Labels of the 
form CamelCaseKey-value basically create new key/value metadata pairs, and the 
project admin can control the taxonomy. I believe it comes with a sensible 
default set.

   http://code.google.com/p/support/wiki/IssueTracker

It looks like you can set up Google Code Subversion repo as a read-only mirror 
of the git trunk. This would probably permit the VCS-issue tracker integration.

   http://code.google.com/p/support/wiki/ImportingFromGit
 
http://code.google.com/p/support/wiki/IssueTracker#Integration_with_version_control

Both Launchpad's bug tracker and Google Code's issue tracker have Python APIs, 
so perhaps you could migrate the individual issues.

   http://code.google.com/p/support/wiki/IssueTrackerAPIPython
   https://help.launchpad.net/API

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco