From: Thomas Harning <harningt@gmail.com>
To: <git@vger.kernel.org>
Subject: [RFC] Idea for Git Bugtracking Tool
Date: Thu, 6 Mar 2008 14:22:46 -0500 [thread overview]
Message-ID: <20080306142246.5d9460b7@gmail.com> (raw)
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?
next reply other threads:[~2008-03-06 19:23 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-06 19:22 Thomas Harning [this message]
2008-03-06 20:08 ` [RFC] Idea for Git Bugtracking Tool Matthieu Moy
2008-03-07 23:10 ` Jakub Narebski
2008-03-08 13:42 ` Pierre Habouzit
2008-03-08 14:23 ` Jakub Narebski
2008-03-08 15:02 ` Pierre Habouzit
2008-03-09 8:26 ` Jan Hudec
2008-03-11 3:29 ` Thomas Harning
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080306142246.5d9460b7@gmail.com \
--to=harningt@gmail.com \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).