Home » Mailing list archives » git » 2008 » March » 6

[RFC] Idea for Git Bugtracking Tool

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
[view in full thread]
From: Thomas Harning
Subject: [RFC] Idea for Git Bugtracking Tool
Date: Thursday, March 6, 2008 - 12:22 pm

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?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
Messages in current thread:
[RFC] Idea for Git Bugtracking Tool, Thomas Harning, (Thu Mar 6, 12:22 pm)
Re: [RFC] Idea for Git Bugtracking Tool, Matthieu Moy, (Thu Mar 6, 1:08 pm)
Re: [RFC] Idea for Git Bugtracking Tool, Jakub Narebski, (Fri Mar 7, 4:10 pm)
Re: [RFC] Idea for Git Bugtracking Tool, Pierre Habouzit, (Sat Mar 8, 6:42 am)
Re: [RFC] Idea for Git Bugtracking Tool, Jakub Narebski, (Sat Mar 8, 7:23 am)
Re: [RFC] Idea for Git Bugtracking Tool, Pierre Habouzit, (Sat Mar 8, 8:02 am)
Re: [RFC] Idea for Git Bugtracking Tool, Jan Hudec, (Sun Mar 9, 1:26 am)
Re: [RFC] Idea for Git Bugtracking Tool, Thomas Harning, (Mon Mar 10, 8:29 pm)