[IPython-dev] Bug handling: launchpad, github, other?
Fri Apr 16 00:09:53 CDT 2010
On Thu, Apr 15, 2010 at 3:23 PM, Robert Kern <email@example.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
>> 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.
I too like the google issue tracker. That and the one for github are
probably my favorites.
> 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.
> Both Launchpad's bug tracker and Google Code's issue tracker have Python APIs,
> so perhaps you could migrate the individual issues.
> 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
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
More information about the IPython-dev