Idea for Git Bugtracking Tool
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?
Quoted 2 lines · Thomas Harning
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.
Signature · 1 line
Matthieu
Quoted 11 lines · Matthieu Moy
Quoted 2 lines · Thomas Harning
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
Signature · 3 lines
Jakub Narebski ShadeHawk on #git Poland
Quoted 7 lines · Jakub Narebski
Quoted 5 lines · Matthieu Moy
Quoted 2 lines · Thomas Harning
Any ideas/flaws with this concept? Anybody up for taking on this project... or for taking this up as a GSOC project mentor?
Quoted 8 lines
Quoted 6 lines
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.
Signature · 3 lines
·O· Pierre Habouzit ··O [email protected] OOO http://www.madism.org
Quoted 10 lines · Pierre Habouzit
Quoted 9 lines · Jakub Narebski
Quoted 7 lines · Matthieu Moy
Quoted 2 lines · Thomas Harning
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:
Quoted 8 lines
Quoted 6 lines
Quoted 4 lines
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)?
Quoted 2 lines
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?
Signature · 2 lines
Jakub Narebski Poland
Quoted 16 lines · Jakub Narebski
Quoted 15 lines · Pierre Habouzit
Quoted 14 lines · Jakub Narebski
Quoted 11 lines · Matthieu Moy
Quoted 2 lines · Thomas Harning
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.
Quoted 7 lines
Quoted 3 lines
Quoted 1 line
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.
Quoted 4 lines
Quoted 2 lines
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.
Signature · 3 lines
·O· Pierre Habouzit ··O [email protected] OOO http://www.madism.org
Quoted 8 lines · Jakub Narebski
[...]
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.
Quoted 3 lines
* 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.
Quoted 3 lines
* 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.
Signature · 1 line
Jan 'Bulb' Hudec <[email protected]>
Quoted 4 lines · On Fri, 07 Mar 2008 15:10:18 -0800 (PST) Jakub Narebski <[email protected]>…
* 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.
Quoted 3 lines
* 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...
Quoted 4 lines
* 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...