[IPython-dev] Bug handling: launchpad, github, other?
Thu Apr 15 17:23:36 CDT 2010
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
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.
"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
More information about the IPython-dev