[RFC] Idea for Git Bugtracking Tool

[RFC] Idea for Git Bugtracking Tool

[Thomas Harning]

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?

Re: [RFC] Idea for Git Bugtracking Tool

[Matthieu Moy]

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

Re: [RFC] Idea for Git Bugtracking Tool

[Jakub Narebski]

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 ?


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

Re: [RFC] Idea for Git Bugtracking Tool

[Pierre Habouzit]

[-- Attachment #1: Type: text/plain, Size: 965 bytes --]

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. 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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [RFC] Idea for Git Bugtracking Tool

[Jakub Narebski]

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)?

> 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

Re: [RFC] Idea for Git Bugtracking Tool

[Pierre Habouzit]

[-- Attachment #1: Type: text/plain, Size: 1622 bytes --]

On Sat, Mar 08, 2008 at 02:23:13PM +0000, Jakub Narebski wrote:
> 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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [RFC] Idea for Git Bugtracking Tool

[Jan Hudec]

On Fri, Mar 07, 2008 at 15:10:18 -0800, Jakub Narebski wrote:
> [...]
> 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>

Re: [RFC] Idea for Git Bugtracking Tool

[Thomas Harning]

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...