{"thread":{"id":"12546","subject":"[RFC] Idea for Git Bugtracking Tool","startedAt":"2008-03-06T19:22:46Z","lastAt":"2008-03-11T03:29:17Z","messageCount":8,"participants":["Thomas Harning","Matthieu Moy","Jakub Narebski","Pierre Habouzit","Jan Hudec"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"71267","messageId":"20080306142246.5d9460b7@gmail.com","threadId":"12546","inReplyTo":null,"subject":"[RFC] Idea for Git Bugtracking Tool","fromName":"Thomas Harning","fromEmail":"harningt@gmail.com","sentAt":"2008-03-06T19:22:46Z","receivedAt":"2008-03-06T19:22:46Z","isPatch":false,"sender":{"key":"harningt@gmail.com","avatar":"https://gravatar.com/avatar/a79ddd43da8c8f1f899cd75b7b95cc5f3b2ba5643400468988b1a12c86b75d08?d=mp&s=160"},"body":"Here's a 'basic' concept on how bugtracking could work w/ GIT\n\nEntities:\n * BUG: Bug Repository\n * GIT: GIT Repository\n---- May be co-located...\n\nIdea:\n * BUG\n Receives bug reports referencing GIT revision ID(s) to which it affects\n Generates unique IDs for bugs (non-incremental,\n although a scheme could be setup ex: -\n Contains a 'cached' calculated BUG-status from GIT log messages\n + permanent BUG-status changes\n Older status change takes precedence (need to make sure times are\n in sync, for sure!)\n * GIT\n Commit messages/annotated-tags may contain text denoting\n a bug's \"new\" status (FIXED/REOPEN/TO-BE-TESTED/...)\n On 'push' to a repository w/ BUG-hooks, trigger 'BUG's\n cache updates\n For 'merge' events, BUG-status changes may get a little more\n ugly and complicated...If a BUG-status change occurs in more\n than 1 branch, the user may need to be alerted that some\n manual checking may be necessary.\n BUG-status changes should probably have the name of the\n branch to which the change occurred, so that when a merge\n occurs, its a little easier to visualize from that, what was\n going on\n\nYou may query BUG for the list of bugs at any point in history and\nit will be able to walk up the list of parents and know what bugs\nexisted where and what changes occurred.\n\nWorkflow enhancement:\n Specific comitters may only be allowed to change the status of\n a bug from OPEN->FIXED, wheras others who state 'FIXED' may\n get the status changed to VERIFY-FIXED or some sort of state\n based on a mapping/workflow tree\n\nIdeally the 'BUG' database can be distributed (potentially within\n a GIT repository...) due to the use of unique IDs. An issue\n here would be dealing w/ the order/time-sensitive bug status changes...\n\nAny ideas/flaws with this concept? Anybody up for taking on this project\n... or for taking this up as a GSOC project mentor?\n"},{"id":"71271","messageId":"vpqskz3pqdo.fsf@bauges.imag.fr","threadId":"12546","inReplyTo":"20080306142246.5d9460b7@gmail.com","subject":"Re: [RFC] Idea for Git Bugtracking Tool","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2008-03-06T20:08:18Z","receivedAt":"2008-03-06T20:08:18Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Thomas Harning writes:\n\n> Any ideas/flaws with this concept? Anybody up for taking on this project\n> ... or for taking this up as a GSOC project mentor?\n\nAlready discussed here:\n\nhttp://thread.gmane.org/gmane.comp.version-control.git/48981/\n\nPierre Habouzit started working on something called grit, which seems\nto be dead.\n\n-- \nMatthieu\n"},{"id":"71387","messageId":"m3zltaf7vs.fsf@localhost.localdomain","threadId":"12546","inReplyTo":"vpqskz3pqdo.fsf@bauges.imag.fr","subject":"Re: [RFC] Idea for Git Bugtracking Tool","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-03-07T23:10:18Z","receivedAt":"2008-03-07T23:10:18Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Matthieu Moy writes:\n\n> Thomas Harning writes:\n> \n>> Any ideas/flaws with this concept? Anybody up for taking on this\n>> project... or for taking this up as a GSOC project mentor?\n> \n> Already discussed here:\n> \n> http://thread.gmane.org/gmane.comp.version-control.git/48981/\n> \n> Pierre Habouzit started working on something called grit, which\n> seems to be dead.\n\nPierre, what happened to git://git.madism.org/grit.git ?\n\n\nThere exists few implementations of distributed bug tracker idea. They\ninclude:\n\n * Bugs Everywhere (http://bugseverywhere.org), written in Python,\n developed in Bazaar, has Git backend support. Formerly written by\n Panoramic Feedback (note that there is stale version of this tool),\n picked up by one of developers\n\n * DisTract (http://www.distract.wellquite.org), written in Haskell,\n uses Monotone as backend. Has good reviews on blogs, e.g. by\n Masukomi.\n\n * DITrack (http://www.ditrack.org), written in Python, currently\n uses Subversion as backend, has plans to be backend-agnostic.\n Inspired by Subissue.\n\nOther links (mainly blogs):\n http://erlangish.blogspot.com/2007/05/distributed-bug-tracking.html\n http://erlangish.blogspot.com/2007/06/distributed-bug-tracking-again.html\n http://weblog.masukomi.org/2008/1/3/distributed-bug-tracking\n http://weblog.masukomi.org/2008/1/20/more-thoughts-on-the-future-of-distributed-bug-tracking\n http://www.geekfire.com/~alex/blog/entries/Ideas-for-a-distributed-bug-tracking-system/Ideas-for-a-distributed-bug-tracking-system.html\n\n-- \nJakub Narebski\nShadeHawk on #git\nPoland\n"},{"id":"71418","messageId":"20080308134210.GA3230@artemis.madism.org","threadId":"12546","inReplyTo":"m3zltaf7vs.fsf@localhost.localdomain","subject":"Re: [RFC] Idea for Git Bugtracking Tool","fromName":"Pierre Habouzit","fromEmail":"madcoder@debian.org","sentAt":"2008-03-08T13:42:10Z","receivedAt":"2008-03-08T13:42:10Z","isPatch":false,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":"On Fri, Mar 07, 2008 at 11:10:18PM +0000, Jakub Narebski wrote:\n> Matthieu Moy writes:\n> \n> > Thomas Harning writes:\n> > \n> >> Any ideas/flaws with this concept? Anybody up for taking on this\n> >> project... or for taking this up as a GSOC project mentor?\n> > \n> > Already discussed here:\n> > \n> > http://thread.gmane.org/gmane.comp.version-control.git/48981/\n> > \n> > Pierre Habouzit started working on something called grit, which\n> > seems to be dead.\n> \n> Pierre, what happened to git://git.madism.org/grit.git ?\n\n it was very badly coded, and not going in the proper direction. We\ndiscussed design with Dscho a couple of time, I know how to build such a\ntool in git (at least a bit how) but I never found the time.\n\n-- \n·O· Pierre Habouzit\n··O madcoder@debian.org\nOOO http://www.madism.org\n"},{"id":"71419","messageId":"200803081523.14340.jnareb@gmail.com","threadId":"12546","inReplyTo":"20080308134210.GA3230@artemis.madism.org","subject":"Re: [RFC] Idea for Git Bugtracking Tool","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-03-08T14:23:13Z","receivedAt":"2008-03-08T14:23:13Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Dnia sobota 8. marca 2008 14:42, Pierre Habouzit napisał:\n> On Fri, Mar 07, 2008 at 11:10:18PM +0000, Jakub Narebski wrote:\n>> Matthieu Moy writes:\n>> \n>>> Thomas Harning writes:\n>>> \n>>>> Any ideas/flaws with this concept? Anybody up for taking on this\n>>>> project... or for taking this up as a GSOC project mentor?\n>>> \n>>> Already discussed here:\n>>> \n>>> http://thread.gmane.org/gmane.comp.version-control.git/48981/\n>>> \n>>> Pierre Habouzit started working on something called grit, which\n>>> seems to be dead.\n>> \n>> Pierre, what happened to git://git.madism.org/grit.git ?\n> \n> it was very badly coded, and not going in the proper direction.\n\nShould it be then removed from InterfacesFrontendsAndTools wiki page\n(perhaps putting \"Bugs Everywhere\", with Git as one of supported version\ncontrol backends in its place)?\n\n> We discussed design with Dscho a couple of time, I know how to build\n> such a tool in git (at least a bit how) but I never found the time.\n\nCare to share those thoughts, and what mistakes were made?\n\n-- \nJakub Narebski\nPoland\n"},{"id":"71421","messageId":"20080308150219.GA8536@artemis.madism.org","threadId":"12546","inReplyTo":"200803081523.14340.jnareb@gmail.com","subject":"Re: [RFC] Idea for Git Bugtracking Tool","fromName":"Pierre Habouzit","fromEmail":"madcoder@debian.org","sentAt":"2008-03-08T15:02:19Z","receivedAt":"2008-03-08T15:02:19Z","isPatch":false,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":"On Sat, Mar 08, 2008 at 02:23:13PM +0000, Jakub Narebski wrote:\n> Dnia sobota 8. marca 2008 14:42, Pierre Habouzit napisał:\n> > On Fri, Mar 07, 2008 at 11:10:18PM +0000, Jakub Narebski wrote:\n> >> Matthieu Moy writes:\n> >> \n> >>> Thomas Harning writes:\n> >>> \n> >>>> Any ideas/flaws with this concept? Anybody up for taking on this\n> >>>> project... or for taking this up as a GSOC project mentor?\n> >>> \n> >>> Already discussed here:\n> >>> \n> >>> http://thread.gmane.org/gmane.comp.version-control.git/48981/\n> >>> \n> >>> Pierre Habouzit started working on something called grit, which\n> >>> seems to be dead.\n> >> \n> >> Pierre, what happened to git://git.madism.org/grit.git ?\n> > \n> > it was very badly coded, and not going in the proper direction.\n> \n> Should it be then removed from InterfacesFrontendsAndTools wiki page\n> (perhaps putting \"Bugs Everywhere\", with Git as one of supported version\n> control backends in its place)?\n\n Oh I didn't remembered it was there, yes it should be removed.\n\n> > We discussed design with Dscho a couple of time, I know how to build\n> > such a tool in git (at least a bit how) but I never found the time.\n> \n> Care to share those thoughts, and what mistakes were made?\n\n I'll try to post a summary of the design/thoughts we had back then at\nsome point, I don't have the time _right now_ though. I'll keep you\nposted.\n\n-- \n·O· Pierre Habouzit\n··O madcoder@debian.org\nOOO http://www.madism.org\n"},{"id":"71494","messageId":"20080309082640.GA22732@efreet.light.src","threadId":"12546","inReplyTo":"m3zltaf7vs.fsf@localhost.localdomain","subject":"Re: [RFC] Idea for Git Bugtracking Tool","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2008-03-09T08:26:40Z","receivedAt":"2008-03-09T08:26:40Z","isPatch":false,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"On Fri, Mar 07, 2008 at 15:10:18 -0800, Jakub Narebski wrote:\n> [...]\n> There exists few implementations of distributed bug tracker idea. They\n> include:\n> \n> * Bugs Everywhere (http://bugseverywhere.org), written in Python,\n> developed in Bazaar, has Git backend support. Formerly written by\n> Panoramic Feedback (note that there is stale version of this tool),\n> picked up by one of developers\n\nI recall Pierre mentioning that he didn't like some things on this back then\nwhen he talked about Grit. Particularly, I believe, the way it suggested to\nhave the bugs in the same branch as source to keep them in sync. It might be\npossible to use it in different way though.\n\n> * DisTract (http://www.distract.wellquite.org), written in Haskell,\n> uses Monotone as backend. Has good reviews on blogs, e.g. by\n> Masukomi.\n\nSounds a little overcomplicated with the monotone storage and firefox UI.\n\n> * DITrack (http://www.ditrack.org), written in Python, currently\n> uses Subversion as backend, has plans to be backend-agnostic.\n> Inspired by Subissue.\n\nI wish them good luck. The problem is, that this is /not/ distributed,\nbecause they use sequential bug numbers, which they'd have to change if they\nwanted to use Git.\n\n-- \n\t\t\t\t\t\t Jan 'Bulb' Hudec \n"},{"id":"71648","messageId":"20080310232917.7c71ccbe@shiva","threadId":"12546","inReplyTo":"m3zltaf7vs.fsf@localhost.localdomain","subject":"Re: [RFC] Idea for Git Bugtracking Tool","fromName":"Thomas Harning","fromEmail":"harningt@gmail.com","sentAt":"2008-03-11T03:29:17Z","receivedAt":"2008-03-11T03:29:17Z","isPatch":false,"sender":{"key":"harningt@gmail.com","avatar":"https://gravatar.com/avatar/a79ddd43da8c8f1f899cd75b7b95cc5f3b2ba5643400468988b1a12c86b75d08?d=mp&s=160"},"body":"On Fri, 07 Mar 2008 15:10:18 -0800 (PST)\nJakub Narebski wrote:\n\n> * Bugs Everywhere (http://bugseverywhere.org), written in Python,\n> developed in Bazaar, has Git backend support. Formerly written by\n> Panoramic Feedback (note that there is stale version of this tool),\n> picked up by one of developers\nThis doesn't appear to let you mark bugs as existing at previous points\nin history... which partly removes the usefulness of branch tracking....\n\nGrit has the same problems it seems... (at least at the state it was\nthe last time I saw it).. besides the problem of being gone.\n> * DisTract (http://www.distract.wellquite.org), written in Haskell,\n> uses Monotone as backend. Has good reviews on blogs, e.g. by\n> Masukomi.\nMonotone+Haskell+Local Firefox... doesn't look like this will go far\nin the real world where people w/o the entire actual would like to post\nbugs...\n> \n> * DITrack (http://www.ditrack.org), written in Python, currently\n> uses Subversion as backend, has plans to be backend-agnostic.\n> Inspired by Subissue.\nDoesn't seem to be able to deal w/ branches particularly... looks more\nlike a way to work as an offline-capable bug tracking system...\n\nI've posted up a wiki @ http://www.eharning.us/wiki/stick/ for a\nworking concept for how a branch-tracking w/ possibility for\ndistribution... Feel free to comment on the page or (preferable) use\nthe Discussion page...\n"}]}