Re: [RFC] git integrated bugtracking

From: Yann Dirson <ydirson@altern.org>
Date: Jun 3, 2007, 12:35 UTC
Message-ID: <20070603123510.GC6992@nan92-1-81-57-214-146.fbx.proxad.net>
In-Reply-To: <20070603114843.GA14336@artemis>

On Sun, Jun 03, 2007 at 01:48:44PM +0200, Pierre Habouzit wrote:

>   Hi, I'm currently trying to think about a bug tracking system that
> would be tightly integrated with git, meaning that it would have to be
> somehow decentralized.

You may want to look at existing solutions, such as Bugs Everywhere[1], which has is modular wrt the backend SCM (supports Arch and Bazaar for now).

I'm not sure its storage format is extensible enough, but it at least shows some interesting ideas.

Show 5 quoted lines

>   I mean, the immediate idea is to have some .bugs/ directories (or
> alike). This has many good properties, e.g. for projects like the linux
> kernel with its many subsystems or driver, it would make sense to have
> per driver/subsystems/... bug packs, and move bugs from one pack to
> another would be the way of assigning bugs to different modules.

What about a requirement that .bugs/ is at the project toplevel ? We could then enforce that such an "assign to submodule" operation only assigns a bug to a real git submodule.

Show 13 quoted lines

>   The other problem I see is that at the time a bug gets reported, the
> user knows it's found at a commit say 'X'. But it could in fact have
> been generated at a commit Y, with this pattern:
> 
>   --o---o---Y---o---o---o---o---X---o---o--> master
>                      \
>                       o---o---o---o---o---o--> branch B
> 
> 
>   Sadly, the bug report has been commited at 'X', hence it does taints
> branch B. As "inserting" or "moving" 'X' commit before the branch is not
> an option as it would rewrite history, that becomes also a major no-go
> for in-tree collecting of bugs.

Maybe "commit annotations" would help here ? I have noticed a thread about a git-note tool, though did not open it yet - so I may be off-track here.

Show 11 quoted lines

> PS: What I left over, is why I wanted such a tool. Programmers tends (or
>     say I tend to, maybe I'm over-generalizing, but I seem to remember a
>     thread on the lkml where Linus was basically saying the same) to
>     hate bugzillas and such out-of-tree tool because they suck, and do
>     not really fit in the programming cycle. I'd rather see a
>     bugtracking system where the backend is in-tree, basically mboxes so
>     that you can read them easily with your favourite MUA, as well as
>     adding new comments in it the same way. It also accommodates with
>     linux-like workflows where bugs usually are sent on the lkml, a bit
>     like patches and pull requests are handled. That's the reasons why I
>     came with this idea.

I still have mixed feelings towards the idea of implementing a brand new defect-tracking system, when there are already so many of them, with many features already. Eg., my initial opinion about Bugs Everywhere was that it was not complete enough to be used in many projects.

I tend to think it would be more productive to do any necessary changes in widely-used bug trackers (bugzilla, mantis, rt...), and work on glue tools, like scmbug[2].

[1] http://www.panoramicfeedback.com/opensource/ [2] http://www.mkgnu.net/?q=scmbug

(both projects listed in the wiki already - http://git.or.cz/gitwiki/InterfacesFrontendsAndToolsWishlist)

best regards, -- Yann.