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

[Brian Granger]

On Thu, Apr 15, 2010 at 3:23 PM, Robert Kern <robert.kern at gmail.com> wrote:
> 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

I too like the google issue tracker.  That and the one for github are
probably my favorites.

Brian

> 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
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>



-- 
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
bgranger at calpoly.edu
ellisonbg at gmail.com