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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
