threads / rfc / 12546

[RFC] Idea for Git Bugtracking Tool

Subject: [RFC] Idea for Git Bugtracking Tool

## tl;dr

8 messages between Mar 6, 2008 and Mar 11, 2008.

replies: 7people: 5as markdown or json

Thomas Harning· Mar 6, 2008, 19:22 UTC · lore
Here's a 'basic' concept on how bugtracking could work w/ GIT
Entities:
  * BUG: Bug Repository
  * GIT: GIT Repository
---- May be co-located...
Idea:
  * BUG
    Receives bug reports referencing GIT revision ID(s) to which it affects
    Generates unique IDs for bugs (non-incremental,
      although a scheme could be setup ex: <UNIQUE-USER>-<INC ID>
    Contains a 'cached' calculated BUG-status from GIT log messages
      + permanent BUG-status changes
    Older status change takes precedence (need to make sure times are
      in sync, for sure!)
  * GIT
    Commit messages/annotated-tags may contain text denoting
      a bug's "new" status (FIXED/REOPEN/TO-BE-TESTED/...)
    On 'push' to a repository w/ BUG-hooks, trigger 'BUG's
      cache updates
    For 'merge' events, BUG-status changes may get a little more
      ugly and complicated...If a BUG-status change occurs in more
      than 1 branch, the user may need to be alerted that some
      manual checking may be necessary.
    BUG-status changes should probably have the name of the
      branch to which the change occurred, so that when a merge
      occurs, its a little easier to visualize from that, what was
      going on

You may query BUG for the list of bugs at any point in history and it will be able to walk up the list of parents and know what bugs existed where and what changes occurred.

Workflow enhancement:
  Specific comitters may only be allowed to change the status of
    a bug from OPEN->FIXED, wheras others who state 'FIXED' may
    get the status changed to VERIFY-FIXED or some sort of state
    based on a mapping/workflow tree
Ideally the 'BUG' database can be distributed (potentially within
  a GIT repository...) due to the use of unique IDs.  An issue
  here would be dealing w/ the order/time-sensitive bug status changes...

Any ideas/flaws with this concept? Anybody up for taking on this project ... or for taking this up as a GSOC project mentor?

Matthieu Moy· Mar 6, 2008, 20:08 UTC · re: Thomas Harning · lore

Re: [RFC] Idea for Git Bugtracking Tool

Thomas Harning <harningt@gmail.com> writes:
> Any ideas/flaws with this concept?  Anybody up for taking on this project
> ... or for taking this up as a GSOC project mentor?
Already discussed here:
http://thread.gmane.org/gmane.comp.version-control.git/48981/

Pierre Habouzit started working on something called grit, which seems to be dead.

-- 
Matthieu
Jakub Narebski· Mar 7, 2008, 23:10 UTC · re: Matthieu Moy · lore

Re: [RFC] Idea for Git Bugtracking Tool

Matthieu Moy <Matthieu.Moy@imag.fr> writes:
Show 11 quoted lines
> Thomas Harning <harningt@gmail.com> writes:
> 
>> Any ideas/flaws with this concept?  Anybody up for taking on this
>> project... or for taking this up as a GSOC project mentor?
> 
> Already discussed here:
> 
> http://thread.gmane.org/gmane.comp.version-control.git/48981/
> 
> Pierre Habouzit started working on something called grit, which
> seems to be dead.
Pierre, what happened to git://git.madism.org/grit.git ?

There exists few implementations of distributed bug tracker idea. They include:

 * Bugs Everywhere (http://bugseverywhere.org), written in Python,
   developed in Bazaar, has Git backend support. Formerly written by
   Panoramic Feedback (note that there is stale version of this tool),
   picked up by one of developers
 * DisTract (http://www.distract.wellquite.org), written in Haskell,
   uses Monotone as backend. Has good reviews on blogs, e.g. by
   Masukomi.
 * DITrack (http://www.ditrack.org), written in Python, currently
   uses Subversion as backend, has plans to be backend-agnostic.
   Inspired by Subissue.
Other links (mainly blogs):
 http://erlangish.blogspot.com/2007/05/distributed-bug-tracking.html
 http://erlangish.blogspot.com/2007/06/distributed-bug-tracking-again.html
 http://weblog.masukomi.org/2008/1/3/distributed-bug-tracking
 http://weblog.masukomi.org/2008/1/20/more-thoughts-on-the-future-of-distributed-bug-tracking
 http://www.geekfire.com/~alex/blog/entries/Ideas-for-a-distributed-bug-tracking-system/Ideas-for-a-distributed-bug-tracking-system.html
-- 
Jakub Narebski
ShadeHawk on #git
Poland
Pierre Habouzit· Mar 8, 2008, 13:42 UTC · re: Jakub Narebski · lore

Re: [RFC] Idea for Git Bugtracking Tool

On Fri, Mar 07, 2008 at 11:10:18PM +0000, Jakub Narebski wrote:
Show 15 quoted lines
> Matthieu Moy <Matthieu.Moy@imag.fr> writes:
> 
> > Thomas Harning <harningt@gmail.com> writes:
> > 
> >> Any ideas/flaws with this concept?  Anybody up for taking on this
> >> project... or for taking this up as a GSOC project mentor?
> > 
> > Already discussed here:
> > 
> > http://thread.gmane.org/gmane.comp.version-control.git/48981/
> > 
> > Pierre Habouzit started working on something called grit, which
> > seems to be dead.
> 
> Pierre, what happened to git://git.madism.org/grit.git ?
  it was very badly coded, and not going in the proper direction. We
discussed design with Dscho a couple of time, I know how to build such a
tool in git (at least a bit how) but I never found the time.
-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org
Jakub Narebski· Mar 8, 2008, 14:23 UTC · re: Pierre Habouzit · lore

Re: [RFC] Idea for Git Bugtracking Tool

Dnia sobota 8. marca 2008 14:42, Pierre Habouzit napisał:
Show 18 quoted lines
> On Fri, Mar 07, 2008 at 11:10:18PM +0000, Jakub Narebski wrote:
>> Matthieu Moy <Matthieu.Moy@imag.fr> writes:
>> 
>>> Thomas Harning <harningt@gmail.com> writes:
>>> 
>>>> Any ideas/flaws with this concept?  Anybody up for taking on this
>>>> project... or for taking this up as a GSOC project mentor?
>>> 
>>> Already discussed here:
>>> 
>>> http://thread.gmane.org/gmane.comp.version-control.git/48981/
>>> 
>>> Pierre Habouzit started working on something called grit, which
>>> seems to be dead.
>> 
>> Pierre, what happened to git://git.madism.org/grit.git ?
> 
>   it was very badly coded, and not going in the proper direction.

Should it be then removed from InterfacesFrontendsAndTools wiki page (perhaps putting "Bugs Everywhere", with Git as one of supported version control backends in its place)?

> We discussed design with Dscho a couple of time, I know how to build
> such a tool in git (at least a bit how) but I never found the time.
Care to share those thoughts, and what mistakes were made?
-- 
Jakub Narebski
Poland
Pierre Habouzit· Mar 8, 2008, 15:02 UTC · re: Jakub Narebski · lore

Re: [RFC] Idea for Git Bugtracking Tool

On Sat, Mar 08, 2008 at 02:23:13PM +0000, Jakub Narebski wrote:
Show 23 quoted lines
> Dnia sobota 8. marca 2008 14:42, Pierre Habouzit napisał:
> > On Fri, Mar 07, 2008 at 11:10:18PM +0000, Jakub Narebski wrote:
> >> Matthieu Moy <Matthieu.Moy@imag.fr> writes:
> >> 
> >>> Thomas Harning <harningt@gmail.com> writes:
> >>> 
> >>>> Any ideas/flaws with this concept?  Anybody up for taking on this
> >>>> project... or for taking this up as a GSOC project mentor?
> >>> 
> >>> Already discussed here:
> >>> 
> >>> http://thread.gmane.org/gmane.comp.version-control.git/48981/
> >>> 
> >>> Pierre Habouzit started working on something called grit, which
> >>> seems to be dead.
> >> 
> >> Pierre, what happened to git://git.madism.org/grit.git ?
> > 
> >   it was very badly coded, and not going in the proper direction.
> 
> Should it be then removed from InterfacesFrontendsAndTools wiki page
> (perhaps putting "Bugs Everywhere", with Git as one of supported version
> control backends in its place)?
  Oh I didn't remembered it was there, yes it should be removed.
> > We discussed design with Dscho a couple of time, I know how to build
> > such a tool in git (at least a bit how) but I never found the time.
> 
> Care to share those thoughts, and what mistakes were made?
  I'll try to post a summary of the design/thoughts we had back then at
some point, I don't have the time _right now_ though. I'll keep you
posted.
-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org
Jan Hudec· Mar 9, 2008, 08:26 UTC · re: Jakub Narebski · lore

Re: [RFC] Idea for Git Bugtracking Tool

On Fri, Mar 07, 2008 at 15:10:18 -0800, Jakub Narebski wrote:
Show 8 quoted lines
> [...]
> There exists few implementations of distributed bug tracker idea. They
> include:
> 
>  * Bugs Everywhere (http://bugseverywhere.org), written in Python,
>    developed in Bazaar, has Git backend support. Formerly written by
>    Panoramic Feedback (note that there is stale version of this tool),
>    picked up by one of developers

I recall Pierre mentioning that he didn't like some things on this back then when he talked about Grit. Particularly, I believe, the way it suggested to have the bugs in the same branch as source to keep them in sync. It might be possible to use it in different way though.

>  * DisTract (http://www.distract.wellquite.org), written in Haskell,
>    uses Monotone as backend. Has good reviews on blogs, e.g. by
>    Masukomi.
Sounds a little overcomplicated with the monotone storage and firefox UI.
>  * DITrack (http://www.ditrack.org), written in Python, currently
>    uses Subversion as backend, has plans to be backend-agnostic.
>    Inspired by Subissue.

I wish them good luck. The problem is, that this is /not/ distributed, because they use sequential bug numbers, which they'd have to change if they wanted to use Git.

-- 
						 Jan 'Bulb' Hudec <bulb@ucw.cz>
Thomas Harning· Mar 11, 2008, 03:29 UTC · re: Jakub Narebski · lore

Re: [RFC] Idea for Git Bugtracking Tool

On Fri, 07 Mar 2008 15:10:18 -0800 (PST) Jakub Narebski <jnareb@gmail.com> wrote:

>  * Bugs Everywhere (http://bugseverywhere.org), written in Python,
>    developed in Bazaar, has Git backend support. Formerly written by
>    Panoramic Feedback (note that there is stale version of this tool),
>    picked up by one of developers

This doesn't appear to let you mark bugs as existing at previous points in history... which partly removes the usefulness of branch tracking....

Grit has the same problems it seems... (at least at the state it was the last time I saw it).. besides the problem of being gone.

>  * DisTract (http://www.distract.wellquite.org), written in Haskell,
>    uses Monotone as backend. Has good reviews on blogs, e.g. by
>    Masukomi.

Monotone+Haskell+Local Firefox... doesn't look like this will go far in the real world where people w/o the entire actual would like to post bugs...

> 
>  * DITrack (http://www.ditrack.org), written in Python, currently
>    uses Subversion as backend, has plans to be backend-agnostic.
>    Inspired by Subissue.

Doesn't seem to be able to deal w/ branches particularly... looks more like a way to work as an offline-capable bug tracking system...

I've posted up a wiki @ http://www.eharning.us/wiki/stick/ for a working concept for how a branch-tracking w/ possibility for distribution... Feel free to comment on the page or (preferable) use the Discussion page...

← back to recent threads