{"thread":{"id":"8409","subject":"[RFC] git integrated bugtracking","startedAt":"2007-06-03T11:48:44Z","lastAt":"2007-06-12T08:54:36Z","messageCount":46,"participants":["Pierre Habouzit","Yann Dirson","Michael Poole","Johan Herland","Matthieu Moy","david@lang.hm","Linus Torvalds","Martin Waitz","Rogan Dawes","Jakub Narebski","Daniel Barkalow","Martin Langhoff","Junio C Hamano","Johannes Schindelin","Jan Hudec","Jon Loeliger","Guilhem Bonnefille"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"43856","messageId":"20070603114843.GA14336@artemis","threadId":"8409","inReplyTo":null,"subject":"[RFC] git integrated bugtracking","fromName":"Pierre Habouzit","fromEmail":"madcoder@debian.org","sentAt":"2007-06-03T11:48:44Z","receivedAt":"2007-06-03T11:48:44Z","isPatch":false,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":"  Hi, I'm currently trying to think about a bug tracking system that\nwould be tightly integrated with git, meaning that it would have to be\nsomehow decentralized.\n\n  Though there is a few design issues I have, that block me from doing\nfirst decisions about how to implement some kind of Proof of Concept. My\nmain problem is: should I put this bug tracking system in the repository\nit tracks bugs for, or not.\n\n  I mean, the immediate idea is to have some .bugs/ directories (or\nalike). This has many good properties, e.g. for projects like the linux\nkernel with its many subsystems or driver, it would make sense to have\nper driver/subsystems/... bug packs, and move bugs from one pack to\nanother would be the way of assigning bugs to different modules.\n\n  Also, a good thing is that when you \"report\" a bug, it gets commited\nin the repository, and taints all the commit chilren, until you commit\nthe closing patch. This allow a release manager to rapidly _see_ if his\nstable branch has this or this bug.\n\n  OTOH it comes with many problems. First, and most obvious IMHO, it's\nthat it'll mean bugs will have to be pulled into the mainlines. Let's\ntake example with the linux repository, I'm not sure Linus would be\nreally keen on doing rounds of bugs pulls, not to mention it'll bloat\nthe repository somehow.\n\n  The other problem I see is that at the time a bug gets reported, the\nuser knows it's found at a commit say 'X'. But it could in fact have\nbeen generated at a commit Y, with this pattern:\n\n  --o---o---Y---o---o---o---o---X---o---o--> master\n                     \\\n                      o---o---o---o---o---o--> branch B\n\n\n  Sadly, the bug report has been commited at 'X', hence it does taints\nbranch B. As \"inserting\" or \"moving\" 'X' commit before the branch is not\nan option as it would rewrite history, that becomes also a major no-go\nfor in-tree collecting of bugs.\n\n  Last of all, I'd also like to have a design where bugs pulls do not\ncreate too much painful merges and conflicts. If we e.g. say that a bug\nis a status file and a mbox of comments (makes sense to me), the mbox\ncan be merged easily (concatenate all mboxes, and purge duplicates), but\nthe status file is quite problematic on its own too.\n\n  So here are the first ideas/problems/remarks I have with that. I'd\nbe thrilled to have your comments about those points.\n\nPS: What I left over, is why I wanted such a tool. Programmers tends (or\n    say I tend to, maybe I'm over-generalizing, but I seem to remember a\n    thread on the lkml where Linus was basically saying the same) to\n    hate bugzillas and such out-of-tree tool because they suck, and do\n    not really fit in the programming cycle. I'd rather see a\n    bugtracking system where the backend is in-tree, basically mboxes so\n    that you can read them easily with your favourite MUA, as well as\n    adding new comments in it the same way. It also accommodates with\n    linux-like workflows where bugs usually are sent on the lkml, a bit\n    like patches and pull requests are handled. That's the reasons why I\n    came with this idea.\n\n-- \n·O·  Pierre Habouzit\n··O                                                madcoder@debian.org\nOOO                                                http://www.madism.org\n"},{"id":"43859","messageId":"20070603123510.GC6992@nan92-1-81-57-214-146.fbx.proxad.net","threadId":"8409","inReplyTo":"20070603114843.GA14336@artemis","subject":"Re: [RFC] git integrated bugtracking","fromName":"Yann Dirson","fromEmail":"ydirson@altern.org","sentAt":"2007-06-03T12:35:10Z","receivedAt":"2007-06-03T12:35:10Z","isPatch":false,"sender":{"key":"ydirson@altern.org","avatar":"https://avatars.githubusercontent.com/u/1190950?v=4"},"body":"On Sun, Jun 03, 2007 at 01:48:44PM +0200, Pierre Habouzit wrote:\n>   Hi, I'm currently trying to think about a bug tracking system that\n> would be tightly integrated with git, meaning that it would have to be\n> somehow decentralized.\n\nYou may want to look at existing solutions, such as Bugs\nEverywhere[1], which has is modular wrt the backend SCM (supports Arch\nand Bazaar for now).\n\nI'm not sure its storage format is extensible enough, but it at least\nshows some interesting ideas.\n\n\n>   I mean, the immediate idea is to have some .bugs/ directories (or\n> alike). This has many good properties, e.g. for projects like the linux\n> kernel with its many subsystems or driver, it would make sense to have\n> per driver/subsystems/... bug packs, and move bugs from one pack to\n> another would be the way of assigning bugs to different modules.\n\nWhat about a requirement that .bugs/ is at the project toplevel ?  We\ncould then enforce that such an \"assign to submodule\" operation only\nassigns a bug to a real git submodule.\n\n\n>   The other problem I see is that at the time a bug gets reported, the\n> user knows it's found at a commit say 'X'. But it could in fact have\n> been generated at a commit Y, with this pattern:\n> \n>   --o---o---Y---o---o---o---o---X---o---o--> master\n>                      \\\n>                       o---o---o---o---o---o--> branch B\n> \n> \n>   Sadly, the bug report has been commited at 'X', hence it does taints\n> branch B. As \"inserting\" or \"moving\" 'X' commit before the branch is not\n> an option as it would rewrite history, that becomes also a major no-go\n> for in-tree collecting of bugs.\n\nMaybe \"commit annotations\" would help here ?  I have noticed a thread\nabout a git-note tool, though did not open it yet - so I may be\noff-track here.\n\n\n> PS: What I left over, is why I wanted such a tool. Programmers tends (or\n>     say I tend to, maybe I'm over-generalizing, but I seem to remember a\n>     thread on the lkml where Linus was basically saying the same) to\n>     hate bugzillas and such out-of-tree tool because they suck, and do\n>     not really fit in the programming cycle. I'd rather see a\n>     bugtracking system where the backend is in-tree, basically mboxes so\n>     that you can read them easily with your favourite MUA, as well as\n>     adding new comments in it the same way. It also accommodates with\n>     linux-like workflows where bugs usually are sent on the lkml, a bit\n>     like patches and pull requests are handled. That's the reasons why I\n>     came with this idea.\n\nI still have mixed feelings towards the idea of implementing a brand\nnew defect-tracking system, when there are already so many of them,\nwith many features already.  Eg., my initial opinion about Bugs\nEverywhere was that it was not complete enough to be used in many\nprojects.\n\nI tend to think it would be more productive to do any necessary\nchanges in widely-used bug trackers (bugzilla, mantis, rt...), and\nwork on glue tools, like scmbug[2].\n\n[1] http://www.panoramicfeedback.com/opensource/\n[2] http://www.mkgnu.net/?q=scmbug\n\n(both projects listed in the wiki already -\nhttp://git.or.cz/gitwiki/InterfacesFrontendsAndToolsWishlist)\n\nbest regards,\n--\nYann.\n"},{"id":"43866","messageId":"878xb19ot5.fsf@graviton.dyn.troilus.org","threadId":"8409","inReplyTo":"20070603114843.GA14336@artemis","subject":"Re: [RFC] git integrated bugtracking","fromName":"Michael Poole","fromEmail":"mdpoole@troilus.org","sentAt":"2007-06-03T12:59:18Z","receivedAt":"2007-06-03T12:59:18Z","isPatch":false,"sender":{"key":"mdpoole@troilus.org","avatar":null},"body":"Pierre Habouzit writes:\n\n>   Hi, I'm currently trying to think about a bug tracking system that\n> would be tightly integrated with git, meaning that it would have to be\n> somehow decentralized.\n>\n>   Though there is a few design issues I have, that block me from doing\n> first decisions about how to implement some kind of Proof of Concept. My\n> main problem is: should I put this bug tracking system in the repository\n> it tracks bugs for, or not.\n>\n>   I mean, the immediate idea is to have some .bugs/ directories (or\n> alike). This has many good properties, e.g. for projects like the linux\n> kernel with its many subsystems or driver, it would make sense to have\n> per driver/subsystems/... bug packs, and move bugs from one pack to\n> another would be the way of assigning bugs to different modules.\n>\n>   Also, a good thing is that when you \"report\" a bug, it gets commited\n> in the repository, and taints all the commit chilren, until you commit\n> the closing patch. This allow a release manager to rapidly _see_ if his\n> stable branch has this or this bug.\n>\n>   OTOH it comes with many problems. First, and most obvious IMHO, it's\n> that it'll mean bugs will have to be pulled into the mainlines. Let's\n> take example with the linux repository, I'm not sure Linus would be\n> really keen on doing rounds of bugs pulls, not to mention it'll bloat\n> the repository somehow.\n>\n>   The other problem I see is that at the time a bug gets reported, the\n> user knows it's found at a commit say 'X'. But it could in fact have\n> been generated at a commit Y, with this pattern:\n>\n>   --o---o---Y---o---o---o---o---X---o---o--> master\n>                      \\\n>                       o---o---o---o---o---o--> branch B\n\nMainly for that reason, I would suggest having it outside the code\nbase's namespace: probably a different root in the same $GIT_DIR, but\nI can see people wanting to have a separate $GIT_DIR.  If the database\ntracks bugs by what commit(s) introduce or expose the bug -- at least\nonce that is known -- then you get nearly free tracking of which\nbranches have the bug without having to check out largely redundant\ntrees.\n\nMichael Poole\n"},{"id":"43867","messageId":"20070603132355.GC14336@artemis","threadId":"8409","inReplyTo":"20070603123510.GC6992@nan92-1-81-57-214-146.fbx.proxad.net","subject":"Re: [RFC] git integrated bugtracking","fromName":"Pierre Habouzit","fromEmail":"madcoder@debian.org","sentAt":"2007-06-03T13:23:55Z","receivedAt":"2007-06-03T13:23:55Z","isPatch":false,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":"On Sun, Jun 03, 2007 at 02:35:10PM +0200, Yann Dirson wrote:\n> On Sun, Jun 03, 2007 at 01:48:44PM +0200, Pierre Habouzit wrote:\n> >   Hi, I'm currently trying to think about a bug tracking system that\n> > would be tightly integrated with git, meaning that it would have to be\n> > somehow decentralized.\n> \n> You may want to look at existing solutions, such as Bugs\n> Everywhere[1], which has is modular wrt the backend SCM (supports Arch\n> and Bazaar for now).\n> \n> I'm not sure its storage format is extensible enough, but it at least\n> shows some interesting ideas.\n\n  I looked at it, the idea is good, implementation quite wrong (too many\nfiles, with too much crancky formats). But it's quite small, so if it's\nthe good way, it should be easy to adapt.\n\n> >   I mean, the immediate idea is to have some .bugs/ directories (or\n> > alike). This has many good properties, e.g. for projects like the linux\n> > kernel with its many subsystems or driver, it would make sense to have\n> > per driver/subsystems/... bug packs, and move bugs from one pack to\n> > another would be the way of assigning bugs to different modules.\n> \n> What about a requirement that .bugs/ is at the project toplevel ?\n\n  I don't see why it's necessary, it's just random thoughts and quite\noutside the scope of my concerns right now.\n\n\n> >   The other problem I see is that at the time a bug gets reported, the\n> > user knows it's found at a commit say 'X'. But it could in fact have\n> > been generated at a commit Y, with this pattern:\n> > \n> >   --o---o---Y---o---o---o---o---X---o---o--> master\n> >                      \\\n> >                       o---o---o---o---o---o--> branch B\n> > \n> > \n> >   Sadly, the bug report has been commited at 'X', hence it does taints\n> > branch B. As \"inserting\" or \"moving\" 'X' commit before the branch is not\n> > an option as it would rewrite history, that becomes also a major no-go\n> > for in-tree collecting of bugs.\n> \n> Maybe \"commit annotations\" would help here ?  I have noticed a thread\n> about a git-note tool, though did not open it yet - so I may be\n> off-track here.\n\n  Hmm, I'll try to search for it then.\n> > PS: What I left over, is why I wanted such a tool. Programmers tends (or\n> >     say I tend to, maybe I'm over-generalizing, but I seem to remember a\n> >     thread on the lkml where Linus was basically saying the same) to\n> >     hate bugzillas and such out-of-tree tool because they suck, and do\n> >     not really fit in the programming cycle. I'd rather see a\n> >     bugtracking system where the backend is in-tree, basically mboxes so\n> >     that you can read them easily with your favourite MUA, as well as\n> >     adding new comments in it the same way. It also accommodates with\n> >     linux-like workflows where bugs usually are sent on the lkml, a bit\n> >     like patches and pull requests are handled. That's the reasons why I\n> >     came with this idea.\n> \n> I still have mixed feelings towards the idea of implementing a brand\n> new defect-tracking system, when there are already so many of them,\n> with many features already.  Eg., my initial opinion about Bugs\n> Everywhere was that it was not complete enough to be used in many\n> projects.\n> \n> I tend to think it would be more productive to do any necessary\n> changes in widely-used bug trackers (bugzilla, mantis, rt...), and\n> work on glue tools, like scmbug[2].\n\n  Well, why writing yet-another-scm like err git ? Because other were\ndoing things wrong. Bugzilla, or especially rt are not distributed,\nhence completely inadequate for use with git, whatever clumsy plumbing\nyou do to make them work. And I know what I'm talking about, I wrote the\nplumbing for the debian bug tracking system, I've looked at a lot of\nthem. And only bugs everywhere was near what looks the good way, because\nwhen you're able to deal with your code like git allows you to, it makes\nabsolutely no sense not being able to deal with your bug database the\nsame way.\n\n  And FWIW I'm just asking questions, nothing more, just because I don't\nwant to rush in yet-another-tool if it appears it will be broken.\n\n-- \n·O·  Pierre Habouzit\n··O                                                madcoder@debian.org\nOOO                                                http://www.madism.org\n"},{"id":"43868","messageId":"20070603133109.GD14336@artemis","threadId":"8409","inReplyTo":"878xb19ot5.fsf@graviton.dyn.troilus.org","subject":"Re: [RFC] git integrated bugtracking","fromName":"Pierre Habouzit","fromEmail":"madcoder@debian.org","sentAt":"2007-06-03T13:31:09Z","receivedAt":"2007-06-03T13:31:09Z","isPatch":false,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":"On Sun, Jun 03, 2007 at 08:59:18AM -0400, Michael Poole wrote:\n> Pierre Habouzit writes:\n>\n> >   The other problem I see is that at the time a bug gets reported, the\n> > user knows it's found at a commit say 'X'. But it could in fact have\n> > been generated at a commit Y, with this pattern:\n> >\n> >   --o---o---Y---o---o---o---o---X---o---o--> master\n> >                      \\\n> >                       o---o---o---o---o---o--> branch B\n> \n> Mainly for that reason, I would suggest having it outside the code\n> base's namespace: probably a different root in the same $GIT_DIR, but\n> I can see people wanting to have a separate $GIT_DIR.  If the database\n> tracks bugs by what commit(s) introduce or expose the bug -- at least\n> once that is known -- then you get nearly free tracking of which\n> branches have the bug without having to check out largely redundant\n> trees.\n\n  Sure, but if it's completely out-of-tree, then cloning a repository\ndon't allow you to get the bug databases with it for free. I mean it'd\nbe great to have it somehow linked to the repository, but also I agree\nthat not everybody wants to clone the whole bugs databases. So maybe it\nshould just be in another shadow branch that annotates the devel ones.\nHmmm I definitely need to read the git-note thread...\n\n-- \n·O·  Pierre Habouzit\n··O                                                madcoder@debian.org\nOOO                                                http://www.madism.org\n"},{"id":"43872","messageId":"200706031548.30111.johan@herland.net","threadId":"8409","inReplyTo":"20070603133109.GD14336@artemis","subject":"Re: [RFC] git integrated bugtracking","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2007-06-03T13:48:29Z","receivedAt":"2007-06-03T13:48:29Z","isPatch":false,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Sunday 03 June 2007, Pierre Habouzit wrote:\n> On Sun, Jun 03, 2007 at 08:59:18AM -0400, Michael Poole wrote:\n> > Pierre Habouzit writes:\n> >\n> > >   The other problem I see is that at the time a bug gets reported, the\n> > > user knows it's found at a commit say 'X'. But it could in fact have\n> > > been generated at a commit Y, with this pattern:\n> > >\n> > >   --o---o---Y---o---o---o---o---X---o---o--> master\n> > >                      \\\n> > >                       o---o---o---o---o---o--> branch B\n> > \n> > Mainly for that reason, I would suggest having it outside the code\n> > base's namespace: probably a different root in the same $GIT_DIR, but\n> > I can see people wanting to have a separate $GIT_DIR.  If the database\n> > tracks bugs by what commit(s) introduce or expose the bug -- at least\n> > once that is known -- then you get nearly free tracking of which\n> > branches have the bug without having to check out largely redundant\n> > trees.\n> \n>   Sure, but if it's completely out-of-tree, then cloning a repository\n> don't allow you to get the bug databases with it for free. I mean it'd\n> be great to have it somehow linked to the repository, but also I agree\n> that not everybody wants to clone the whole bugs databases. So maybe it\n> should just be in another shadow branch that annotates the devel ones.\n> Hmmm I definitely need to read the git-note thread...\n\nI guess I'm the one responsible for starting that git-note thread...\n\nFor the moment, I'm busy implementing some concepts that came out of that \ndiscussion (refactoring tag objects and building some infrastructure needed \nto support notes without the drawbacks present in my first version).\n\nHopefully I'll have a proof-of-concept ready before too long. In the \nmeantime I'll be happy to answer questions you might have.\n\nRegarding the notes themselves, I thought about possibly using them as a \nlink between the repo and the bug tracker, with some glue code in between \nfor making the connections. I haven't thought about integrating them more \ndeeply into a bug tracker, but it might be worth thinking along those \nlines, especially for the kind of system you're proposing.\n\nNow, back to hacking...\n\n\nHave fun! :)\n\n...Johan\n\n\n-- \nJohan Herland, <johan@herland.net>\nwww.herland.net\n"},{"id":"43882","messageId":"20070603151921.GB30347@artemis","threadId":"8409","inReplyTo":"200706031548.30111.johan@herland.net","subject":"Re: [RFC] git integrated bugtracking","fromName":"Pierre Habouzit","fromEmail":"madcoder@debian.org","sentAt":"2007-06-03T15:19:21Z","receivedAt":"2007-06-03T15:19:21Z","isPatch":false,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":"On Sun, Jun 03, 2007 at 03:48:29PM +0200, Johan Herland wrote:\n> On Sunday 03 June 2007, Pierre Habouzit wrote:\n> > On Sun, Jun 03, 2007 at 08:59:18AM -0400, Michael Poole wrote:\n> > > Pierre Habouzit writes:\n> > >\n> > > >   The other problem I see is that at the time a bug gets reported, the\n> > > > user knows it's found at a commit say 'X'. But it could in fact have\n> > > > been generated at a commit Y, with this pattern:\n> > > >\n> > > >   --o---o---Y---o---o---o---o---X---o---o--> master\n> > > >                      \\\n> > > >                       o---o---o---o---o---o--> branch B\n> > > \n> > > Mainly for that reason, I would suggest having it outside the code\n> > > base's namespace: probably a different root in the same $GIT_DIR, but\n> > > I can see people wanting to have a separate $GIT_DIR.  If the database\n> > > tracks bugs by what commit(s) introduce or expose the bug -- at least\n> > > once that is known -- then you get nearly free tracking of which\n> > > branches have the bug without having to check out largely redundant\n> > > trees.\n> > \n> >   Sure, but if it's completely out-of-tree, then cloning a repository\n> > don't allow you to get the bug databases with it for free. I mean it'd\n> > be great to have it somehow linked to the repository, but also I agree\n> > that not everybody wants to clone the whole bugs databases. So maybe it\n> > should just be in another shadow branch that annotates the devel ones.\n> > Hmmm I definitely need to read the git-note thread...\n> \n> I guess I'm the one responsible for starting that git-note thread...\n> \n> For the moment, I'm busy implementing some concepts that came out of that \n> discussion (refactoring tag objects and building some infrastructure needed \n> to support notes without the drawbacks present in my first version).\n> \n> Hopefully I'll have a proof-of-concept ready before too long. In the \n> meantime I'll be happy to answer questions you might have.\n> \n> Regarding the notes themselves, I thought about possibly using them as a \n> link between the repo and the bug tracker, with some glue code in between \n> for making the connections. I haven't thought about integrating them more \n> deeply into a bug tracker, but it might be worth thinking along those \n> lines, especially for the kind of system you're proposing.\n\n  Yeah, now that I read that thread, well yeah, I think notes are a hell\nof a good concept for my ideas. I mean, a bug report would be basically\na collection of notes:\n  * the bug has been found at this commit ;\n  * the bug has been not-found at this commit ;\n  * this commit is a fix for that bug ;\n  * this commit enhance features for that wish and so on.\nSome other bits are more followup comments and are disconnected to\ncommits, but could be attached to the \"bug object\" whatever would be\nused for bugs, the whole concept is blurry anyways, we're just\ndiscussing ideas :)\n\n  Though, for a good bug tracking system, you need to be able to answer\nsome kind of questions fast enough:\n  * list bugs that affect a given stage of the repository\n    (tag/branch/commit/...) ;\n  * be able to trace history of a given bug (yes, it's fairly obvious,\n    but unlike many other bug tracking systems, for us it would not be\n    contiguous, so it's not necessarily a O(1) operation) ;\n\n  Other things nice to have is textual search, git-grep can help of\ncourse, but that's an operation you do often with a bug tracking system,\nand you expect it to be faster than git-grep is (though maybe an\noptionnal index can be built around the notes for that purpose and not\nbe versionned ?).\n\n  Another think that notes do not address are another operation we\nusually do on bugs: merge (or duplicates). There is a think I hate in\nbugzilla and love in debbugs, it's that duplicate bugs are closed in the\nformer, and merged in the latter. When two bugs are the same, their\nhistory are often *both* valuable, and you really don't want to lose one\nhalf, you want to merge them. And you also want the option to \"unmerge\"\nthem, but for that the better option is to have the ability to duplicate\na bug (aka debbugs cloning).\n\n  Anyways it's just gossip, but maybe someone will have a brilliant\nideas, so I'm just throwing my thoughts into this mail :)\n\n-- \n·O·  Pierre Habouzit\n··O                                                madcoder@debian.org\nOOO                                                http://www.madism.org\n"},{"id":"43884","messageId":"vpq1wgtnith.fsf@bauges.imag.fr","threadId":"8409","inReplyTo":"20070603151921.GB30347@artemis","subject":"Re: [RFC] git integrated bugtracking","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2007-06-03T15:44:58Z","receivedAt":"2007-06-03T15:44:58Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Pierre Habouzit <madcoder@debian.org> writes:\n\n>   Yeah, now that I read that thread, well yeah, I think notes are a hell\n> of a good concept for my ideas. I mean, a bug report would be basically\n> a collection of notes:\n>   * the bug has been found at this commit ;\n>   * the bug has been not-found at this commit ;\n>   * this commit is a fix for that bug ;\n\nThat's my feeling too. \"Commiting\" bug information in the tree is only\nhalf of a good idea. You want to be able to say, after the fact, \"This\ncommit had bug XYZ\". OTOH, the idea (followed by bugs everywhere) that\nmerging a branch would automatically close bugs fixed by this branch\nis a really cool thing.\n\nThe kind of information you're mentionning above can be a great\nstarting point for \"bisect\". I can even imagine a kind of distributed\nbisect, where several users could give their \"bad commits\" for the\nsame bug.\n\n-- \nMatthieu\n"},{"id":"43886","messageId":"20070603160736.GC30347@artemis","threadId":"8409","inReplyTo":"vpq1wgtnith.fsf@bauges.imag.fr","subject":"Re: [RFC] git integrated bugtracking","fromName":"Pierre Habouzit","fromEmail":"madcoder@debian.org","sentAt":"2007-06-03T16:07:36Z","receivedAt":"2007-06-03T16:07:36Z","isPatch":false,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":"On Sun, Jun 03, 2007 at 05:44:58PM +0200, Matthieu Moy wrote:\n> Pierre Habouzit <madcoder@debian.org> writes:\n> \n> >   Yeah, now that I read that thread, well yeah, I think notes are a hell\n> > of a good concept for my ideas. I mean, a bug report would be basically\n> > a collection of notes:\n> >   * the bug has been found at this commit ;\n> >   * the bug has been not-found at this commit ;\n> >   * this commit is a fix for that bug ;\n> \n> That's my feeling too. \"Commiting\" bug information in the tree is only\n> half of a good idea. You want to be able to say, after the fact, \"This\n> commit had bug XYZ\". OTOH, the idea (followed by bugs everywhere) that\n> merging a branch would automatically close bugs fixed by this branch\n> is a really cool thing.\n\n  That would work with notes, as while merging you'll get the notes of\nthe commit in your branch, *and* the note about the fixing patch. So\nthere is no loss of \"concept\" here. In fact that was the thing that I\nlooked for. Notes are good. They just may not be enough to write an\nin-git bugtracking tool, as a bug needs the \"notes collection\" concepts,\nand maybe a few other.\n\n> The kind of information you're mentionning above can be a great\n> starting point for \"bisect\". I can even imagine a kind of distributed\n> bisect, where several users could give their \"bad commits\" for the\n> same bug.\n\n  Heh yes. Sometimes it's more complex than that as bugs can come back\n(regressions) or be the result of many commits (like the cases that suck\nwith bisect). For a complex bug it's more a set of [found..notfound[\nintervals. Though this indeed is very valuable information, and the\ndistributed component thing *is* great.\n\n-- \n·O·  Pierre Habouzit\n··O                                                madcoder@debian.org\nOOO                                                http://www.madism.org\n"},{"id":"43887","messageId":"20070603171040.GE6992@nan92-1-81-57-214-146.fbx.proxad.net","threadId":"8409","inReplyTo":"20070603151921.GB30347@artemis","subject":"Re: [RFC] git integrated bugtracking","fromName":"Yann Dirson","fromEmail":"ydirson@altern.org","sentAt":"2007-06-03T17:10:40Z","receivedAt":"2007-06-03T17:10:40Z","isPatch":false,"sender":{"key":"ydirson@altern.org","avatar":"https://avatars.githubusercontent.com/u/1190950?v=4"},"body":"On Sun, Jun 03, 2007 at 05:19:21PM +0200, Pierre Habouzit wrote:\n>   Another think that notes do not address are another operation we\n> usually do on bugs: merge (or duplicates). There is a think I hate in\n> bugzilla and love in debbugs, it's that duplicate bugs are closed in the\n> former, and merged in the latter. When two bugs are the same, their\n> history are often *both* valuable, and you really don't want to lose one\n> half, you want to merge them. And you also want the option to \"unmerge\"\n> them, but for that the better option is to have the ability to duplicate\n> a bug (aka debbugs cloning).\n\nI can't wait for visualising the history of bugreports in gitk, along\nwith duplicates/forks and merges :)\n\n>   Anyways it's just gossip, but maybe someone will have a brilliant\n> ideas, so I'm just throwing my thoughts into this mail :)\n\n/me wishes all gossip would be as productive as this one :)\n\nBest regards,\n-- \nYann\n"},{"id":"43890","messageId":"Pine.LNX.4.64.0706031031520.6705@asgard.lang.hm","threadId":"8409","inReplyTo":"20070603160736.GC30347@artemis","subject":"Re: [RFC] git integrated bugtracking","fromName":"","fromEmail":"david@lang.hm","sentAt":"2007-06-03T17:35:48Z","receivedAt":"2007-06-03T17:35:48Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Sun, 3 Jun 2007, Pierre Habouzit wrote:\n\n> On Sun, Jun 03, 2007 at 05:44:58PM +0200, Matthieu Moy wrote:\n>> Pierre Habouzit <madcoder@debian.org> writes:\n>>\n>>>   Yeah, now that I read that thread, well yeah, I think notes are a hell\n>>> of a good concept for my ideas. I mean, a bug report would be basically\n>>> a collection of notes:\n>>>   * the bug has been found at this commit ;\n>>>   * the bug has been not-found at this commit ;\n>>>   * this commit is a fix for that bug ;\n>>\n>> That's my feeling too. \"Commiting\" bug information in the tree is only\n>> half of a good idea. You want to be able to say, after the fact, \"This\n>> commit had bug XYZ\". OTOH, the idea (followed by bugs everywhere) that\n>> merging a branch would automatically close bugs fixed by this branch\n>> is a really cool thing.\n>\n>  That would work with notes, as while merging you'll get the notes of\n> the commit in your branch, *and* the note about the fixing patch. So\n> there is no loss of \"concept\" here. In fact that was the thing that I\n> looked for. Notes are good. They just may not be enough to write an\n> in-git bugtracking tool, as a bug needs the \"notes collection\" concepts,\n> and maybe a few other.\n\nhow would you identify bugs in such a way that they will match up when you \nmerge different trees?\n\nif you can manage to do this it sounds like a great idea. but I'm not \nseeing a good way to do it at the moment. the answer may be a combination \nof a number of factors.\n\n1. bug number doesn't work well in a distributed environment\n\n2. something based on indentifying the cause of the bug (commit id + file \n+ line????) will only work after you know the real cause of the bug\n\n3. description is worthless, too many ways to describe things that have \nthe same underlying cause\n\nDavid Lang\n"},{"id":"43897","messageId":"20070603184957.GE30347@artemis","threadId":"8409","inReplyTo":"Pine.LNX.4.64.0706031031520.6705@asgard.lang.hm","subject":"Re: [RFC] git integrated bugtracking","fromName":"Pierre Habouzit","fromEmail":"madcoder@debian.org","sentAt":"2007-06-03T18:49:57Z","receivedAt":"2007-06-03T18:49:57Z","isPatch":false,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":"On Sun, Jun 03, 2007 at 10:35:48AM -0700, david@lang.hm wrote:\n> On Sun, 3 Jun 2007, Pierre Habouzit wrote:\n> \n> >On Sun, Jun 03, 2007 at 05:44:58PM +0200, Matthieu Moy wrote:\n> >>Pierre Habouzit <madcoder@debian.org> writes:\n> >>\n> >>>  Yeah, now that I read that thread, well yeah, I think notes are a \n> >>>hell\n> >>>of a good concept for my ideas. I mean, a bug report would be \n> >>>basically\n> >>>a collection of notes:\n> >>>  * the bug has been found at this commit ;\n> >>>  * the bug has been not-found at this commit ;\n> >>>  * this commit is a fix for that bug ;\n> >>\n> >>That's my feeling too. \"Commiting\" bug information in the tree is only\n> >>half of a good idea. You want to be able to say, after the fact, \"This\n> >>commit had bug XYZ\". OTOH, the idea (followed by bugs everywhere) that\n> >>merging a branch would automatically close bugs fixed by this branch\n> >>is a really cool thing.\n> >\n> > That would work with notes, as while merging you'll get the notes of\n> >the commit in your branch, *and* the note about the fixing patch. So\n> >there is no loss of \"concept\" here. In fact that was the thing that I\n> >looked for. Notes are good. They just may not be enough to write an\n> >in-git bugtracking tool, as a bug needs the \"notes collection\" concepts,\n> >and maybe a few other.\n> \n> how would you identify bugs in such a way that they will match up when \n> you merge different trees?\n\n  well, because they will be sha1's, a git object. And when it's a\nduplicate, well, let's face it, not bugtracker helps *automatically*\ntracking duplicates. The merge work is up to the QA people. Yeah,\nbugtracker won't do all the tracking. In a way, that's good, that means\nthere is still place for humans in that world :)\n\n> if you can manage to do this it sounds like a great idea. but I'm not \n> seeing a good way to do it at the moment. the answer may be a combination \n> of a number of factors.\n> \n> 1. bug number doesn't work well in a distributed environment\n\n  Sure, SCM revisions either. But git solved that once, I don't see why\nthe solution found at that time would be less of a solution now :)\n\n> 2. something based on indentifying the cause of the bug (commit id + file \n> + line????) will only work after you know the real cause of the bug\n\n  It does not work in a real world, where real user don't grok code.\n\n> 3. description is worthless, too many ways to describe things that have \n> the same underlying cause\n\n  Sure, though it could help finding dupes. BUt in my experience what\nhelps most, is fine grained categorizing, because you end up with few\nbugs for a given component, and \"same\" bugs end up actually being near\nin the UI or query tool. Of course it let space for bugs that get\nactually miscategorized. But hell, my experience is also that many bugs\nare discovered as beeing fixed years after the fix anyway.\n\n  I don't plan fixing all that stuff, it can't really be. I just would\nlike to create a tool that isn't as painful for the programmer as\nbugzilla (or rt or ...) is, while it would still be as pleasant and easy\nto stick a web UI for the users over it, hence not making the user\nexperience less pleasant.\n\n  My experience with bugtracking is that the most efficient way to deal\nit is to let the programmer in charge of the responsible module deal\nwith those bugs. What programmer aren't willing to do is the triaging,\nand pulling the bugs off a distant database/UI/.. off something that\nisn't in their usual workflow.\n-- \n·O·  Pierre Habouzit\n··O                                                madcoder@debian.org\nOOO                                                http://www.madism.org\n"},{"id":"43898","messageId":"Pine.LNX.4.64.0706031203220.6705@asgard.lang.hm","threadId":"8409","inReplyTo":"20070603184957.GE30347@artemis","subject":"Re: [RFC] git integrated bugtracking","fromName":"","fromEmail":"david@lang.hm","sentAt":"2007-06-03T19:07:44Z","receivedAt":"2007-06-03T19:07:44Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Sun, 3 Jun 2007, Pierre Habouzit wrote:\n\n> \n> On Sun, Jun 03, 2007 at 10:35:48AM -0700, david@lang.hm wrote:\n>> On Sun, 3 Jun 2007, Pierre Habouzit wrote:\n>>\n>>> On Sun, Jun 03, 2007 at 05:44:58PM +0200, Matthieu Moy wrote:\n>>>> Pierre Habouzit <madcoder@debian.org> writes:\n>>>>\n>>>>>  Yeah, now that I read that thread, well yeah, I think notes are a\n>>>>> hell\n>>>>> of a good concept for my ideas. I mean, a bug report would be\n>>>>> basically\n>>>>> a collection of notes:\n>>>>>  * the bug has been found at this commit ;\n>>>>>  * the bug has been not-found at this commit ;\n>>>>>  * this commit is a fix for that bug ;\n>>>>\n>>>> That's my feeling too. \"Commiting\" bug information in the tree is only\n>>>> half of a good idea. You want to be able to say, after the fact, \"This\n>>>> commit had bug XYZ\". OTOH, the idea (followed by bugs everywhere) that\n>>>> merging a branch would automatically close bugs fixed by this branch\n>>>> is a really cool thing.\n>>>\n>>> That would work with notes, as while merging you'll get the notes of\n>>> the commit in your branch, *and* the note about the fixing patch. So\n>>> there is no loss of \"concept\" here. In fact that was the thing that I\n>>> looked for. Notes are good. They just may not be enough to write an\n>>> in-git bugtracking tool, as a bug needs the \"notes collection\" concepts,\n>>> and maybe a few other.\n>>\n>> how would you identify bugs in such a way that they will match up when\n>> you merge different trees?\n>\n>  well, because they will be sha1's, a git object. And when it's a\n> duplicate, well, let's face it, not bugtracker helps *automatically*\n> tracking duplicates. The merge work is up to the QA people. Yeah,\n> bugtracker won't do all the tracking. In a way, that's good, that means\n> there is still place for humans in that world :)\n>\n>> if you can manage to do this it sounds like a great idea. but I'm not\n>> seeing a good way to do it at the moment. the answer may be a combination\n>> of a number of factors.\n>>\n>> 1. bug number doesn't work well in a distributed environment\n>\n>  Sure, SCM revisions either. But git solved that once, I don't see why\n> the solution found at that time would be less of a solution now :)\n\ngit's tracking of revisions works becouse it's tracking the content, it \ndoesn't care _how_ the content got that way, if it's the same it's the \nsame and will have the same hash.\n\nwith bugs the reports aren't the same so you can use the sha1 to track a \nparticular entry/tag/comment but not to identify the bug itself\n\n>> 2. something based on indentifying the cause of the bug (commit id + file\n>> + line????) will only work after you know the real cause of the bug\n>\n>  It does not work in a real world, where real user don't grok code.\n>\n>> 3. description is worthless, too many ways to describe things that have\n>> the same underlying cause\n>\n>  Sure, though it could help finding dupes. BUt in my experience what\n> helps most, is fine grained categorizing, because you end up with few\n> bugs for a given component, and \"same\" bugs end up actually being near\n> in the UI or query tool. Of course it let space for bugs that get\n> actually miscategorized. But hell, my experience is also that many bugs\n> are discovered as beeing fixed years after the fix anyway.\n\nfine grained categorization is something that takes place long after the \nbug is reported, users don't know how to correctly categorize bugs any \nmore then they know what code caused the bug.\n\n>  I don't plan fixing all that stuff, it can't really be. I just would\n> like to create a tool that isn't as painful for the programmer as\n> bugzilla (or rt or ...) is, while it would still be as pleasant and easy\n> to stick a web UI for the users over it, hence not making the user\n> experience less pleasant.\n>\n>  My experience with bugtracking is that the most efficient way to deal\n> it is to let the programmer in charge of the responsible module deal\n> with those bugs. What programmer aren't willing to do is the triaging,\n> and pulling the bugs off a distant database/UI/.. off something that\n> isn't in their usual workflow.\n\nthis only works if someone goes to the work to send the bugs to the right \nprogrammer. in many cases this is non-trivial.\n\nDavid Lang\n"},{"id":"43899","messageId":"alpine.LFD.0.98.0706031216560.23741@woody.linux-foundation.org","threadId":"8409","inReplyTo":"20070603114843.GA14336@artemis","subject":"Re: [RFC] git integrated bugtracking","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-06-03T19:22:20Z","receivedAt":"2007-06-03T19:22:20Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sun, 3 Jun 2007, Pierre Habouzit wrote:\n> \n>   Though there is a few design issues I have, that block me from doing\n> first decisions about how to implement some kind of Proof of Concept. My\n> main problem is: should I put this bug tracking system in the repository\n> it tracks bugs for, or not.\n\nMake it a separate (and independent) branch of the repository you track, \nand then you can do it - or not do it - as you want later.\n\nSee as an example the git \"todo\" branch, ie you can always look at what \nJunio may or may not be planning with a\n\n\tgit show remotes/origin/todo:TODO\n\nwhich just shows the \"TODO\" file in the \"remotes/origin/todo\" branch.\n\nThe same approach could be done for bug tracking: you *could* check out \nthe bug-tracking branch separately (and you can create a repository that \nhas _only_ that bug tracking branch, or _only_ the actual development \nbranch in it), but you could also access it without even checking it out \nat all, and mix the two projects in the same repository.\n\n>   I mean, the immediate idea is to have some .bugs/ directories (or\n> alike). This has many good properties, e.g. for projects like the linux\n> kernel with its many subsystems or driver, it would make sense to have\n> per driver/subsystems/... bug packs, and move bugs from one pack to\n> another would be the way of assigning bugs to different modules.\n\nI would suggest _not_ doing this kind of mixing. I think it might be \nappropriate for some cases, but I don't think it's appropriate in general. \nPartly because I don't think the people who change the bugs are at all \nnecessarily at all the same people who actually do development.\n\nIOW, bug-reporters obviously have to have write access to *some* \nbug-tracking thing, and I don't think you want to try to merge the \nbug-tracking together with the real development. \n\n\t\tLinus\n"},{"id":"43902","messageId":"20070603200431.GF6992@nan92-1-81-57-214-146.fbx.proxad.net","threadId":"8409","inReplyTo":"20070603151921.GB30347@artemis","subject":"Re: [RFC] git integrated bugtracking","fromName":"Yann Dirson","fromEmail":"ydirson@altern.org","sentAt":"2007-06-03T20:04:31Z","receivedAt":"2007-06-03T20:04:31Z","isPatch":false,"sender":{"key":"ydirson@altern.org","avatar":"https://avatars.githubusercontent.com/u/1190950?v=4"},"body":"One thing that I just thought about is how such a system would play\nwith eg. StGIT.\n\nPrecisely, if I stick a BTS note (found/not-found probably makes no\nsense here, so that'd mostly be fixes/enhances notes) to a given\nversion of an StGIT patch, I probably want the BTS to be able to tell\nthat the next version of the patch \"probably has\" the same note - if a\ngiven patch fixes a given bug, I infer the patch is primarily written\nas a fix for that bug, so later revisions of the patch (eg. cleanups)\nwould also fix it.  But maybe we'd want the patch author to\nexplicitely make such an assertion, in case a cleanup would have\nbroken the fix - both options could be useful in different cases.\n\nCurrently, old versions of an StGIT patch are only available through\nStGIT patchlogs, which are not ancestors of later versions of the same\npatch.  That is, even the \"subsequent versions inherit notes\" policy\nwould need extra StGIT-aware stuff to work.\n\nThis may be something to keep in mind here - but that issue could also\nbe seen as belonging to the more general (and with ongoing work)\naspect of git/StGIT interactions.  Even better if the 2 ongoing\nreflexions cross-fertilisate :)\n\nBest regards,\n-- \nYann.\n"},{"id":"43904","messageId":"20070603201632.GF30347@artemis","threadId":"8409","inReplyTo":"alpine.LFD.0.98.0706031216560.23741@woody.linux-foundation.org","subject":"Re: [RFC] git integrated bugtracking","fromName":"Pierre Habouzit","fromEmail":"madcoder@debian.org","sentAt":"2007-06-03T20:16:32Z","receivedAt":"2007-06-03T20:16:32Z","isPatch":false,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":"On Sun, Jun 03, 2007 at 12:22:20PM -0700, Linus Torvalds wrote:\n> \n> \n> On Sun, 3 Jun 2007, Pierre Habouzit wrote:\n> > \n> >   Though there is a few design issues I have, that block me from doing\n> > first decisions about how to implement some kind of Proof of Concept. My\n> > main problem is: should I put this bug tracking system in the repository\n> > it tracks bugs for, or not.\n> \n> Make it a separate (and independent) branch of the repository you track, \n> and then you can do it - or not do it - as you want later.\n> \n> See as an example the git \"todo\" branch, ie you can always look at what \n> Junio may or may not be planning with a\n> \n> \tgit show remotes/origin/todo:TODO\n> \n> which just shows the \"TODO\" file in the \"remotes/origin/todo\" branch.\n> \n> The same approach could be done for bug tracking: you *could* check out \n> the bug-tracking branch separately (and you can create a repository that \n> has _only_ that bug tracking branch, or _only_ the actual development \n> branch in it), but you could also access it without even checking it out \n> at all, and mix the two projects in the same repository.\n\n  Well I went that way, but we loose the quite cool \"if I branch my\nrepository I branch the bugs coming with them too\"-feature. And I'd be\nsad to give that up. But maybe it's an error to want to use git to\nencode that relation.\n\n  [10 minutes of pondering later]\n\n  Well yes, I think it's basically an error to encode the bug\ndependencies in git branches and so on, because bug tracking is often\ndone asynchronously from devel. So you'll have to assign bug to parts of\nthe history that are already cold from a devel point of view.\n\n  My conclusion is indeed that a separate branch is really the way to\ngo. That does not tells how I'll be able to answer the usual \"what are\nthe current opened bugs in my branch\" question fast, but well, one step\nat a time.\n\n> >   I mean, the immediate idea is to have some .bugs/ directories (or\n> > alike). This has many good properties, e.g. for projects like the linux\n> > kernel with its many subsystems or driver, it would make sense to have\n> > per driver/subsystems/... bug packs, and move bugs from one pack to\n> > another would be the way of assigning bugs to different modules.\n> \n> I would suggest _not_ doing this kind of mixing. I think it might be \n> appropriate for some cases, but I don't think it's appropriate in general. \n> Partly because I don't think the people who change the bugs are at all \n> necessarily at all the same people who actually do development.\n> \n> IOW, bug-reporters obviously have to have write access to *some* \n> bug-tracking thing, and I don't think you want to try to merge the \n> bug-tracking together with the real development. \n\n  I agree, but I don't see how it's very different from you not trusting\nthe average kernel contributor and wanting your lieutenants to ack\npatches first. My point is, the user-exposed part doesn't *has* to be\npushed in the mainline repository, it could be in ... the bugs\nrepository, from which developpers could pull some bug reports that are\nworth. Or you can also have more layers if you have a QA team in charge\nof the bugs. Possibilities are endless, and well, I don't pretend to be\nthe one that will teach you that :)\n\n  Though I don't like 100% the idea of a .bugs repository. The reason\nwhy I came up with that, is that (experience talking), as a\ndevelopper/maintainer/...whatever I have to get in touch with the\nreporter. Most convenient way : mail. So I want to be able to use\n`$MUA -f /path/to/bug/mbox` to answer, because this is the sole\noperation that makes sense. Though I suppose it could be easy to make a\nthin wrapper that does a local checkout calls $MUA, and commits the new\nmail. So I'd easily give up on that, as I acknowledge I've no real\nreasons to design it that way.\n\n\n-- \n·O·  Pierre Habouzit\n··O                                                madcoder@debian.org\nOOO                                                http://www.madism.org\n"},{"id":"43905","messageId":"20070603201723.GG6992@nan92-1-81-57-214-146.fbx.proxad.net","threadId":"8409","inReplyTo":"alpine.LFD.0.98.0706031216560.23741@woody.linux-foundation.org","subject":"Re: [RFC] git integrated bugtracking","fromName":"Yann Dirson","fromEmail":"ydirson@altern.org","sentAt":"2007-06-03T20:17:23Z","receivedAt":"2007-06-03T20:17:23Z","isPatch":false,"sender":{"key":"ydirson@altern.org","avatar":"https://avatars.githubusercontent.com/u/1190950?v=4"},"body":"On Sun, Jun 03, 2007 at 12:22:20PM -0700, Linus Torvalds wrote:\n> On Sun, 3 Jun 2007, Pierre Habouzit wrote:\n> >   Though there is a few design issues I have, that block me from doing\n> > first decisions about how to implement some kind of Proof of Concept. My\n> > main problem is: should I put this bug tracking system in the repository\n> > it tracks bugs for, or not.\n> \n> Make it a separate (and independent) branch of the repository you track, \n> and then you can do it - or not do it - as you want later.\n\nAnd since we have cheep branches, we can even have one BTS branch for\neach project branch.\n\nBut then, since we probably want git-merge to merge the BTS branch\nwhen present in the local repo, that would mean adding some support in\nthe core porcelain - eg. a config option declaring some coupling\nbetween a branch and its bug-tracking pal, so git-merge can be taught\nto merge it too.\n\n\n> >   I mean, the immediate idea is to have some .bugs/ directories (or\n> > alike). This has many good properties, e.g. for projects like the linux\n> > kernel with its many subsystems or driver, it would make sense to have\n> > per driver/subsystems/... bug packs, and move bugs from one pack to\n> > another would be the way of assigning bugs to different modules.\n> \n> I would suggest _not_ doing this kind of mixing. I think it might be \n> appropriate for some cases, but I don't think it's appropriate in general. \n> Partly because I don't think the people who change the bugs are at all \n> necessarily at all the same people who actually do development.\n\nThe same functionality could probably be obtained through more\nannotations (ie. record which subsystem the bug relates to, just like\nany other property of the bug).\n\nBest regards,\n-- \nYann.\n"},{"id":"43906","messageId":"20070603202117.GG30347@artemis","threadId":"8409","inReplyTo":"20070603200431.GF6992@nan92-1-81-57-214-146.fbx.proxad.net","subject":"Re: [RFC] git integrated bugtracking","fromName":"Pierre Habouzit","fromEmail":"madcoder@debian.org","sentAt":"2007-06-03T20:21:17Z","receivedAt":"2007-06-03T20:21:17Z","isPatch":false,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":"On Sun, Jun 03, 2007 at 10:04:31PM +0200, Yann Dirson wrote:\n> One thing that I just thought about is how such a system would play\n> with eg. StGIT.\n\n  I read the rest of the mail, but I don't know stgit at all, so I'm not\nreally able to tell how well it would integrate, especially since well,\nit's still early.\n\n  But for sure, I'm launching that brainstorming thread because I want\nas much input as possible to know what are people needs, and add the one\nthat make sense to the todo list, the one that would be good to the\nwishlist. FWIW playing well with usual git tools (like stgit, guilt, and\nwhatever other evolved \"thing\" in the git nebula) is definitely in the\nTODO list.\n\n-- \n·O·  Pierre Habouzit\n··O                                                madcoder@debian.org\nOOO                                                http://www.madism.org\n"},{"id":"43907","messageId":"20070603203147.GH6992@nan92-1-81-57-214-146.fbx.proxad.net","threadId":"8409","inReplyTo":"Pine.LNX.4.64.0706031203220.6705@asgard.lang.hm","subject":"Re: [RFC] git integrated bugtracking","fromName":"Yann Dirson","fromEmail":"ydirson@altern.org","sentAt":"2007-06-03T20:31:47Z","receivedAt":"2007-06-03T20:31:47Z","isPatch":false,"sender":{"key":"ydirson@altern.org","avatar":"https://avatars.githubusercontent.com/u/1190950?v=4"},"body":"On Sun, Jun 03, 2007 at 12:07:44PM -0700, david@lang.hm wrote:\n> >>1. bug number doesn't work well in a distributed environment\n> >\n> > Sure, SCM revisions either. But git solved that once, I don't see why\n> >the solution found at that time would be less of a solution now :)\n> \n> git's tracking of revisions works becouse it's tracking the content, it \n> doesn't care _how_ the content got that way, if it's the same it's the \n> same and will have the same hash.\n> \n> with bugs the reports aren't the same so you can use the sha1 to track a \n> particular entry/tag/comment but not to identify the bug itself\n\nDo you see any problem with taking as bug id the hash of the first\nentry submitted ?  Just like in a classical BTS, the bug id gets\nallocated at submussion time.  Further informations then get\nassociated with the initial report - here that would problably\ntranslate into the initial report being an annotation to a source\ncommit, and further information being annotations to the initial\nannotation.\n\n\n> fine grained categorization is something that takes place long after the \n> bug is reported, users don't know how to correctly categorize bugs any \n> more then they know what code caused the bug.\n\nIs that a problem ?\n\n\n> > My experience with bugtracking is that the most efficient way to deal\n> >it is to let the programmer in charge of the responsible module deal\n> >with those bugs. What programmer aren't willing to do is the triaging,\n> >and pulling the bugs off a distant database/UI/.. off something that\n> >isn't in their usual workflow.\n> \n> this only works if someone goes to the work to send the bugs to the right \n> programmer. in many cases this is non-trivial.\n\nThis is he work of a QA team, and although it is not as common in the\nFree Software world as it should be, there are people willing to do\nthe job.  This discussion is about giving these people a better tool\nto help them focus on the tasks where a human being is really needed.\n\nBest regards,\n-- \nYann.\n"},{"id":"43908","messageId":"20070603203229.GH30347@artemis","threadId":"8409","inReplyTo":"20070603201723.GG6992@nan92-1-81-57-214-146.fbx.proxad.net","subject":"Re: [RFC] git integrated bugtracking","fromName":"Pierre Habouzit","fromEmail":"madcoder@debian.org","sentAt":"2007-06-03T20:32:29Z","receivedAt":"2007-06-03T20:32:29Z","isPatch":false,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":"On Sun, Jun 03, 2007 at 10:17:23PM +0200, Yann Dirson wrote:\n> On Sun, Jun 03, 2007 at 12:22:20PM -0700, Linus Torvalds wrote:\n> > On Sun, 3 Jun 2007, Pierre Habouzit wrote:\n> > >   Though there is a few design issues I have, that block me from doing\n> > > first decisions about how to implement some kind of Proof of Concept. My\n> > > main problem is: should I put this bug tracking system in the repository\n> > > it tracks bugs for, or not.\n> > \n> > Make it a separate (and independent) branch of the repository you track, \n> > and then you can do it - or not do it - as you want later.\n> \n> And since we have cheep branches, we can even have one BTS branch for\n> each project branch.\n> \n> But then, since we probably want git-merge to merge the BTS branch\n> when present in the local repo, that would mean adding some support in\n> the core porcelain - eg. a config option declaring some coupling\n> between a branch and its bug-tracking pal, so git-merge can be taught\n> to merge it too.\n\n  In fact, I don't think so. In my answer to Linus, I was almost writing\nthe same thing as you. In fact, no, we don't want a BTS branch per\nproject branch. We just want to be able to list commits where we found\nthe bug, and commits where we didn't found them. Lets call them good and\nbad commits (yeah, ring a bell ;p). One of the \"good\" commit will be\nbetter than any other good one, as it'll be the \"fixing\" commit. Or one\nof the fixing commits, as you may have different ones if you just\ncherry-pick just the patch in a stable branch.\n\n  So what you need is a way to link a bug to git objects, namely\ncommits. Linking to files or subtrees also makes sense. In fact we need\nto link bugs to well git objects (what a shock :D).\n\n  And if you want to know what affects a given branch, well, you need to\nlist bugs whose affected objects are present in that given branch. Even\nif you have one branch per project branch, as the bug branch chronology\nwill not be the same as the project's one, you'll still need to answer\nthe previous question the very same way. And I don't think it's be more\ncomplicated if all project's branches (or may project's branches) are\ndealt with or not.\n\n> > >   I mean, the immediate idea is to have some .bugs/ directories (or\n> > > alike). This has many good properties, e.g. for projects like the linux\n> > > kernel with its many subsystems or driver, it would make sense to have\n> > > per driver/subsystems/... bug packs, and move bugs from one pack to\n> > > another would be the way of assigning bugs to different modules.\n> > \n> > I would suggest _not_ doing this kind of mixing. I think it might be \n> > appropriate for some cases, but I don't think it's appropriate in general. \n> > Partly because I don't think the people who change the bugs are at all \n> > necessarily at all the same people who actually do development.\n> \n> The same functionality could probably be obtained through more\n> annotations (ie. record which subsystem the bug relates to, just like\n> any other property of the bug).\n\n  Well, annotations are certainly useful to create a [git object] ->\n[bug #id] map. That way, listing bugs in a branch is \"just\" a matter of\nlisting still open bugs in the ancestry graph. Sadly, if I'm not\nmistaken, this is at least a linear operation wrt the number of objects\nin the branch (supposing that access to objects is O(1)).  IMHO that's\nnot good enough, but I'm not really in the implementation stage yet.\n\n-- \n·O·  Pierre Habouzit\n··O                                                madcoder@debian.org\nOOO                                                http://www.madism.org\n"},{"id":"43923","messageId":"20070603230702.GC16637@admingilde.org","threadId":"8409","inReplyTo":"20070603201632.GF30347@artemis","subject":"Re: [RFC] git integrated bugtracking","fromName":"Martin Waitz","fromEmail":"tali@admingilde.org","sentAt":"2007-06-03T23:07:03Z","receivedAt":"2007-06-03T23:07:03Z","isPatch":false,"sender":{"key":"tali@admingilde.org","avatar":"https://gravatar.com/avatar/3f89b03eee362187effabe257898735b475673a12265c398ea9161259ae91553?d=mp&s=160"},"body":"hoi :)\n\nOn Sun, Jun 03, 2007 at 10:16:32PM +0200, Pierre Habouzit wrote:\n>   Well I went that way, but we loose the quite cool \"if I branch my\n> repository I branch the bugs coming with them too\"-feature. And I'd be\n> sad to give that up. But maybe it's an error to want to use git to\n> encode that relation.\n\nJust store the commit which introduced the bug (or where the bug\nwas first found) and you will get that, too.  You only have to check\nif this commit is reachable by a given branch to see if it is affected.\nWhen you fix the bug you store the commit id that fixed it and then\nyou can check every branch if it points into bad..good.\n\nYou can also do this for released versions.\nIf you have the bug database inside the repository you can't report\nany bugs for a released version, because it is, well already released.\n\n-- \nMartin Waitz\n"},{"id":"43965","messageId":"4663DC16.8080309@dawes.za.net","threadId":"8409","inReplyTo":"20070603230702.GC16637@admingilde.org","subject":"Re: [RFC] git integrated bugtracking","fromName":"Rogan Dawes","fromEmail":"lists@dawes.za.net","sentAt":"2007-06-04T09:32:06Z","receivedAt":"2007-06-04T09:32:06Z","isPatch":false,"sender":{"key":"lists@dawes.za.net","avatar":null},"body":"Martin Waitz wrote:\n> hoi :)\n> \n> On Sun, Jun 03, 2007 at 10:16:32PM +0200, Pierre Habouzit wrote:\n>>   Well I went that way, but we loose the quite cool \"if I branch my\n>> repository I branch the bugs coming with them too\"-feature. And I'd be\n>> sad to give that up. But maybe it's an error to want to use git to\n>> encode that relation.\n> \n> Just store the commit which introduced the bug (or where the bug\n> was first found) and you will get that, too.  You only have to check\n> if this commit is reachable by a given branch to see if it is affected.\n> When you fix the bug you store the commit id that fixed it and then\n> you can check every branch if it points into bad..good.\n> \n> You can also do this for released versions.\n> If you have the bug database inside the repository you can't report\n> any bugs for a released version, because it is, well already released.\n> \n\nOk, that seems reasonable.\n\nNow, how do you store updates to a bug? i.e. followup questions and answers?\n\nAs suggested in another message, I think that the bug id would have to \nbe the hash of the initial report (incl whatever metadata is considered \ninteresting).\n\nI think that the individual reports might be stored by their id, perhaps \nvia a fan out dir, like the .git/objects directory. Attachments can be \nstored by their hash in a separate directory structure. Modifications to \na report would simply be appended to the original report. Simultaneous \nmodifications could be dealt with by merging the two files, probably \nusing a custom merge driver.\n\nObviously the format of a bug report and follow up message would need to \nbe quite strictly defined and adhered to, for the merge driver to be \nable to do its work with the minimum/zero user interaction.\n\nClosed bugs would be deleted from the filesystem, but would obviously be \navailable via the history.\n\nIndexes or categories could be implemented by means of symlinks/symrefs \nin a different set of \"index directories\". e.g.\n\n/categories/drivers/deadbeef -> ../../bugs/de/adbeef\n/assignedto/joe@example.org/deadbeef -> ../../bugs/de/adbeef\n\nor similar. These might not be strictly necessary, since all that \ninformation will be in the report anyway. Perhaps the indexes would be \nstored simply as cached data, and rebuilt if out of date.\n\nThe porcelain would then take care of presenting the bugs to the user in \nthe preferred format, much like we have gitk, gitweb, qgit, tig, etc.\n\nDoes any of this make sense?\n\nRogan\n"},{"id":"43976","messageId":"466413BC.1080007@dawes.za.net","threadId":"8409","inReplyTo":"20070604102037.GB7758@.intersec.eu","subject":"Re: [RFC] git integrated bugtracking","fromName":"Rogan Dawes","fromEmail":"lists@dawes.za.net","sentAt":"2007-06-04T13:29:32Z","receivedAt":"2007-06-04T13:29:32Z","isPatch":false,"sender":{"key":"lists@dawes.za.net","avatar":null},"body":"Pierre Habouzit wrote:\n\n>   For that part, as the \"right\" way to deal with bugs is IMHO through\n> mail, my heart balance between a ${bug_sha1}.mbox or a ${bug_sha1}/\n> maildir. The former avoids to bloat the files, the latter avoids\n> painless merges (chance to have a conflict in the comments is near zero\n> through maildirs) but would see 3 directories (cur new tmp) be spoiled.\n\nOne downside of using maildir (which I agree has several desirable \nproperties), is that the filenames include characters that are illegal \non various platforms (specifically \":\" in Windows). This is quite \nunfortunate.\n\n>   In addition to that a ${bug_sha1}.status (or alike) flat file would be\n> needed to store metadata about the bug (who it is assigned to, which\n> module/category it's in, ...).\n> \n>   Note that mails are mostly textual, flat, and allow attachments,\n> signature, whatever... and are IMHO very well suited for a bugtracking\n> use.\n\nI think it would be very neat to be able to use the built-in mechanisms \nin mail clients for threading, etc, and handling attachments, sorting \nand filtering. Tracking things like who a bug is assigned to wouldn't \nwork too well, but I imagine that many kernel developers have fine tuned \ntheir email clients to such a degree that it wouldn't be impossible :-)\n\nI'm not familiar with how messages move around in {cur,new,tmp}, but I \nsuspect that if we simply make a convention that all mails are created \nas \"read\", then we won't have clashes between developers holding some \nbugs as unread, etc while others have already read them.\n\n>> Closed bugs would be deleted from the filesystem, but would obviously be \n>> available via the history.\n> \n>   IMHO we should keep the .status file for closed bugs, and use the\n> history to lookup for the content of the mail{box,dir} if needed.\n\nMaybe.\n\n>   Merging is also easy, it's just a matter of merging the \"mails\".\n\nYes.\n\n>   Cloning bugs is just a matter of copying a report.\n> \n>   etc… every usual BTS operation is mapped trivially on FS/git\n> operations. And that's not really surprising, as bugs are contents, and\n> git actually tracks contents right :)\n> \n>> Indexes or categories could be implemented by means of symlinks/symrefs \n>> in a different set of \"index directories\". e.g.\n>>\n>> /categories/drivers/deadbeef -> ../../bugs/de/adbeef\n>> /assignedto/joe@example.org/deadbeef -> ../../bugs/de/adbeef\n>>\n>> or similar. These might not be strictly necessary, since all that \n>> information will be in the report anyway. Perhaps the indexes would be \n>> stored simply as cached data, and rebuilt if out of date.\n> \n>   IMHO that should be in a cache, all valuable information would be in\n> the *.status files anyway, it's just a way to index them. FWIW I think\n> this should be dealt with in a higher level tool. What is needed first\n> for the developer is a way to deal with a bug he knows is here. Dealing\n> with large collection of bugs must be built on top of that, and is easy\n> to keep up to date through proper hooks.\n\nYes, hooks might be the right approach for this.\n\n>   IMHO the sole features it should provide and design specifically are: \n>   * the efficient linking with the rest of the repository (through\n>     annotations, decorations, or whichever implementation) ;\n>   * the storage backend, in a supple enough way to allow usual\n>     operations (threading, answers, attachments, use through mail or\n>     {web,G}ui, ...)\n>   * versioning of the BTS datas.\n> The rest can just be built on top of that.\n\nAgreed.\n\nRogan\n"},{"id":"44007","messageId":"20070604220308.GJ6992@nan92-1-81-57-214-146.fbx.proxad.net","threadId":"8409","inReplyTo":"20070603151921.GB30347@artemis","subject":"Re: [RFC] git integrated bugtracking","fromName":"Yann Dirson","fromEmail":"ydirson@altern.org","sentAt":"2007-06-04T22:03:08Z","receivedAt":"2007-06-04T22:03:08Z","isPatch":false,"sender":{"key":"ydirson@altern.org","avatar":"https://avatars.githubusercontent.com/u/1190950?v=4"},"body":"Another aspect that I have not seen discussed yet is the handling of\ntestcases that expose a bug, and which are usually integrated as\nnon-reg tests afterwards.\n\nIf we're going the way of using git-note's, we can easily link the\ncommit which adds the testcase to the non-reg testsuite.\n\nBut we could be interested in running the testcase against an\narbitrary commit, thus allowing some sort of automated bisect (modulo\napplicability of the testcase to other commits, which may cause false\nnegatives, but also false positives, and thus may need to be\nhand-driven or at least hand-reviewed).\n\nFor this, however, would it be sufficient to have the testcase\ncommitted somewhere in the history tree ?  Our hypothetic automatic\nbisect tool could cherry-pick that commit and run the testcase, but at\nwould place an arbitrary restriction of \"one testcase per commit\",\nwhich would probably a bad idea.\n\nAnd having the annotation point to the blob does not seem a good idea\neither, at least because currently in git tools we have test scripts\nthat excercise several testcases each.\n\nEven an annotation to both a commit and a blob changed by that commit\nwould not be sufficiently accurate, when several testcases are added\nto the same script in a single commit.\n\n\nAnother options would be to embed the testcase in an annotation: I\ncan't really see that being used, since that would duplicate the\ntestcase.  That makes me wonder whether it would not be required to\nhave testcases described in seperate files ?\n\nBest regards,\n-- \nYann.\n"},{"id":"44010","messageId":"20070604222505.GC13902@artemis","threadId":"8409","inReplyTo":"20070604220308.GJ6992@nan92-1-81-57-214-146.fbx.proxad.net","subject":"Re: [RFC] git integrated bugtracking","fromName":"Pierre Habouzit","fromEmail":"madcoder@debian.org","sentAt":"2007-06-04T22:25:05Z","receivedAt":"2007-06-04T22:25:05Z","isPatch":false,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":"On Tue, Jun 05, 2007 at 12:03:08AM +0200, Yann Dirson wrote:\n> Another aspect that I have not seen discussed yet is the handling of\n> testcases that expose a bug, and which are usually integrated as\n> non-reg tests afterwards.\n\n  Well IMHO testcases are to be dealt with from the build sytem, and\nversionned in the SCM. You may want to have some kind of helper doing\nthe bisect automatically for you (though, speaking of experience, it's\nnot always _that_ simple because of broken commits that do not build\ne.g.) But I hardly see how it can be realted to a BTS anyways. I mean,\nbugs will likely have test cases to exhibit the bug, but those should be\nput in the test-case part of the repository. I mean well, maybe there is\nfancy things to do, but I don't think it should be the role of a BTS at\nall.\n\n-- \n·O·  Pierre Habouzit\n··O                                                madcoder@debian.org\nOOO                                                http://www.madism.org\n"},{"id":"44443","messageId":"20070609121244.GA2951@artemis","threadId":"8409","inReplyTo":"20070603114843.GA14336@artemis","subject":"Re: [RFC] git integrated bugtracking","fromName":"Pierre Habouzit","fromEmail":"madcoder@debian.org","sentAt":"2007-06-09T12:12:44Z","receivedAt":"2007-06-09T12:12:44Z","isPatch":false,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":"  FWIW I've begun to work on this (for real). I've called the tool\n\"grit\". You can follow the developpement on:\n\n  * gitweb: http://git.madism.org/?p=grit.git;a=summary\n  * git:    git://git.madism.org/grit.git/\n\nCheers,\n-- \n·O·  Pierre Habouzit\n··O                                                madcoder@debian.org\nOOO                                                http://www.madism.org\n"},{"id":"44453","messageId":"f4ejr5$e3q$1@sea.gmane.org","threadId":"8409","inReplyTo":"20070609121244.GA2951@artemis","subject":"Re: [RFC] git integrated bugtracking","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-06-09T16:23:12Z","receivedAt":"2007-06-09T16:23:12Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Pierre Habouzit wrote:\n\n>   FWIW I've begun to work on this (for real). I've called the tool\n> \"grit\". You can follow the developpement on:\n> \n>   * gitweb: http://git.madism.org/?p=grit.git;a=summary\n>   * git:    git://git.madism.org/grit.git/\n\nI have added info about it at the bottom of\n  http://git.or.cz/gitwiki/InterfacesFrontendsAndTools\n\nFeel free to correct and extend info.\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"44526","messageId":"Pine.LNX.4.64.0706092152180.5848@iabervon.org","threadId":"8409","inReplyTo":"20070609121244.GA2951@artemis","subject":"Re: [RFC] git integrated bugtracking","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2007-06-10T02:44:58Z","receivedAt":"2007-06-10T02:44:58Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Sat, 9 Jun 2007, Pierre Habouzit wrote:\n\n>   FWIW I've begun to work on this (for real). I've called the tool\n> \"grit\". You can follow the developpement on:\n> \n>   * gitweb: http://git.madism.org/?p=grit.git;a=summary\n>   * git:    git://git.madism.org/grit.git/\n\nI've been working on a completely orthogonal portion of the bug-tracking \nproblem (software to try to generate bug reports containing the \ninformation that a particular project would like for a particular sort of \nbug), and I've been thinking about how it would fit in with \ngit-the-content-addressed-filesystem. I haven't actually implemented \nanything at all in this area, some you're ahead of me, but I have some \nideas.\n\n1) It's probably best to use some new types, rather than trees and \ncommits. This gives you more flexibility to structure things in ways that \nexactly fit what's going on, which is one of the main reasons git is so \ngood for version control. It also means that you can use inline strings \nfor short answers (what's the name of the program that makes your kernel \noops), and blobs for long answers (what's your lspci -vvv), and commits \nwhen appropriate (what commit did git-bisect find? what version resolves \nit?)\n\n2) It's probably best to have the history be per-bug, with each revision \nbeing an update to that report, and have the complete database be a refs/ \nsubdirectory. The complete list of bugs is going to become vast, and it's \nprobably best to retain old bugs, at least in the databases at archival \nsites, so that you can get information on how often a bug turns out to be \nmisuse of a particular API or something. This means that you really don't \nwant each addition to be O(number of bugs).\n\n3) I think it's worth separately representing \"what problem somebody had\" \nand \"what was wrong with the program to cause problems\" and linking these \nto each other. This will help in being able to at least represent multiple \nreports of the same bug, which is useful for finding patterns when the bug \nis non-trivial.\n\nMy idea of what the structure of the data is:\n\n - The project has essentially a troubleshooting procedure, written up \n   like a classic expert system (or like Kconfig). This takes the user \n   through a set of all the questions developers ever ask, with only the \n   appropriate ones visible (if you've got a build failure, it doesn't ask \n   for lspci output; it only asks for sysrq-t output if the system is \n   still sort of responding; etc).\n\n - The failure report is the set of all the questions the user answered \n   and the answers.\n\n - The hash of the initial failure report is the ID for the failure. \n   Revisions of the report (adding more information as people ask for \n   special things) retain the same ID.\n\n - After you generate a failure report, it searches for similar failures \n   and bugs in the main database. If it finds stuff, the user can try any \n   resolutions, and skip sending the report in. If there's nothing there \n   or there's still uncertainty as to what to do about the issue or the \n   resolution doesn't work for this case, the report is added to the \n   database.\n\n - It's up to developers to create bug records to pull together failure \n   reports, analysis of the situations, advice, and the ultimate \n   resolution. Failures get revised to link them to bugs so that people \n   with problems can find answers, and bugs list the failures they cause, \n   so that people working on something can find people to test.\n\n - Reports can be made on (1) failures that somebody would be able to test \n   resolutions to, but which aren't attached to any bugs; (2) bugs that \n   aren't resolved in a particular commit (which may be resolved in some \n   later or parallel commit, or have a patch). These are the things that a \n   release engineer would want to check on before releasing.\n\n - Reports can be made on clusters of unattached failures with similar \n   features. This would include unreproduceable failures, because they \n   might become fixable based on a large number of reports, or a test case \n   could be generated that makes them easier to trigger based on \n   distilling the common features of the rare failures.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"44530","messageId":"46a038f90706092359i43a6e834rc096e53a28fbee51@mail.gmail.com","threadId":"8409","inReplyTo":"20070609121244.GA2951@artemis","subject":"Re: [RFC] git integrated bugtracking","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2007-06-10T06:59:13Z","receivedAt":"2007-06-10T06:59:13Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 6/10/07, Pierre Habouzit <madcoder@debian.org> wrote:\n>   FWIW I've begun to work on this (for real). I've called the tool\n> \"grit\". You can follow the developpement on:\n>\n>   * gitweb: http://git.madism.org/?p=grit.git;a=summary\n>   * git:    git://git.madism.org/grit.git/\n\nCall me a fool, but writing a <new> bugtracker looks like a\nboil-the-oceans scheme.\n\nAdding git & gitweb support to traq, bugzilla, mantis, gforge, etc is\nwhat is going to make the difference. Most of those have already the\nability to \"link\" to one or more commits -- after the commits are done\nand in GIT.\n\nSo you can tell your bugtracker\n - which commit fixed it -- usually auto-linked if you include the\nbugnumber in the commit message\n - which commit added the test -- auto linked as above\n - which commit introduced the bug -- if such thing exists and someone\ndigs it up\n\nIf the bugtracker can also auto-link things that look committish in\ntext entered by users (someone might write \"bisect sez that f345e is\nto blame\"), with tooltips indicating in which heads those commits\nresides (like gitk does), then it's just gorgeous.\n\nBut I would _never_ try to describe all the possible relations in the\nschema -- existing trackers use a liberal mix of regexes and cache\ntables with some free form text fields for this kind of stuff.\n\nAnd definitely, if you use git as an alibi to write a new bugtracker,\ndon't use the \"works only with git\" as a feature. It should work with\nas many SCMs as possible.\n\nOTOH, that's just me, I'm lazy and like to work on already-successful\nprojects that are 99% there for my needs (and where I can add that\n1%).\n\ncheers,\n\n\nm\n"},{"id":"44534","messageId":"7v4plgb6t6.fsf@assigned-by-dhcp.cox.net","threadId":"8409","inReplyTo":"46a038f90706092359i43a6e834rc096e53a28fbee51@mail.gmail.com","subject":"Re: [RFC] git integrated bugtracking","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-06-10T07:35:33Z","receivedAt":"2007-06-10T07:35:33Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Martin Langhoff\" <martin.langhoff@gmail.com> writes:\n\n> On 6/10/07, Pierre Habouzit <madcoder@debian.org> wrote:\n>>   FWIW I've begun to work on this (for real). I've called the tool\n>> \"grit\". You can follow the developpement on:\n>>\n>>   * gitweb: http://git.madism.org/?p=grit.git;a=summary\n>>   * git:    git://git.madism.org/grit.git/\n>\n> Call me a fool, but writing a <new> bugtracker looks like a\n> boil-the-oceans scheme.\n>\n> Adding git & gitweb support to traq, bugzilla, mantis, gforge, etc is\n> what is going to make the difference. Most of those have already the\n> ability to \"link\" to one or more commits -- after the commits are done\n> and in GIT.\n\nYou are a brave person to say this (no sarcasm --- I wish I\nwere, too).\n\nOn one hand, I very much applaud and appreciate your comment for\ninjecting sanity to the discussion.  On the other hand, if Linus\nhad such an attitude, we might not be hacking on git right now.\n\nAfter looking at the above existing alternatives, some brave\nsoul might decide and say, \"Hey, I can write something better in\n2 weeks\" ;-).\n\n> So you can tell your bugtracker\n> - which commit fixed it -- usually auto-linked if you include the\n> bugnumber in the commit message\n> - which commit added the test -- auto linked as above\n> - which commit introduced the bug -- if such thing exists and someone\n> digs it up\n\nAll of your examples are going from a single bug to commits, but\nfrom a release person's point of view, you are never interested\nin a single bug, just like a top-level maintainer is never\ninterested in a single file.  A release person would want to go\nin the reverse direction: from a commit range to a set of bugs.\nWhat bugs were fixed and what regressions were introduced during\nthis release cycle.  While embedded ticket numbers in commit log\nmessages would certainly help, a change made to fix a particular\nbug may fix another as its side effect, and the develeoper who\ndid the change may not know about the latter when the commit log\nmessage is written.\n\n> If the bugtracker can also auto-link things that look committish in\n> text entered by users (someone might write \"bisect sez that f345e is\n> to blame\"), with tooltips indicating in which heads those commits\n> resides (like gitk does), then it's just gorgeous.\n>\n> But I would _never_ try to describe all the possible relations in the\n> schema -- existing trackers use a liberal mix of regexes and cache\n> tables with some free form text fields for this kind of stuff.\n\nThese are indeed very good points.\n"},{"id":"44538","messageId":"Pine.LNX.4.64.0706100831310.4059@racer.site","threadId":"8409","inReplyTo":"Pine.LNX.4.64.0706092152180.5848@iabervon.org","subject":"Re: [RFC] git integrated bugtracking","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-06-10T07:44:37Z","receivedAt":"2007-06-10T07:44:37Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 9 Jun 2007, Daniel Barkalow wrote:\n\n> 1) It's probably best to use some new types, rather than trees and \n> commits. This gives you more flexibility to structure things in ways \n> that exactly fit what's going on, which is one of the main reasons git \n> is so good for version control.\n\nI fail to see why this has to be a new type. The flexibility in Git lies \nIMHO therein that it does _not_ have a plethora of objects. Rather, there \nare just 4 object types, which serve their purpose well, indeed. (I would \neven have argued that tag objects could have been simple commit objects, \nwith an additional header \"tag\", but oh well.)\n\nI suspect that you want to introduce a different object type to be able to \nimplement a new algorithm. But I think that the appropriate data structure \nis still contained in the existing set of types in Git.\n\n> 2) It's probably best to have the history be per-bug, with each revision \n> being an update to that report, and have the complete database be a \n> refs/ subdirectory.\n\nI don't think that this is a good solution:\n\n>From the implementation view point, a lot of branches sucks \nperformance-wise. Especially since we do not pack branch refs.\n\nSide note: I recently kicked around the idea to actually keep \nthe refs in the packed-refs file, and for updating refs do a \nlock-mmap-findref-replace-or-rewrite, where a rewrite only happens if we \ndelete or insert a ref.\n\nThen, we could even unify the info/refs and packed-refs, so that we don't \nhear bugreports about http transport not working every week or so.\n\nJust an idea.\n\nCiao,\nDscho\n"},{"id":"44552","messageId":"20070610083754.GC4084@efreet.light.src","threadId":"8409","inReplyTo":"46a038f90706092359i43a6e834rc096e53a28fbee51@mail.gmail.com","subject":"Re: [RFC] git integrated bugtracking","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2007-06-10T08:37:54Z","receivedAt":"2007-06-10T08:37:54Z","isPatch":false,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"On Sun, Jun 10, 2007 at 18:59:13 +1200, Martin Langhoff wrote:\n> On 6/10/07, Pierre Habouzit <madcoder@debian.org> wrote:\n> >  FWIW I've begun to work on this (for real). I've called the tool\n> >\"grit\". You can follow the developpement on:\n> >\n> >  * gitweb: http://git.madism.org/?p=grit.git;a=summary\n> >  * git:    git://git.madism.org/grit.git/\n> \n> Call me a fool, but writing a <new> bugtracker looks like a\n> boil-the-oceans scheme.\n\nI don't know about any *distributed* bug tracker, which is the point here.\n\nWe have several distributed version control tools, but no other distributed\ntools for the other tasks in configuration management.\n\n> Adding git & gitweb support to traq, bugzilla, mantis, gforge, etc is\n> what is going to make the difference.\n\nIt would certainly be useful. But the problem with these bug trackers is,\nthat they don't go all that well with how many hackers work. And the less\nthey fit with distributed workflow.\n\n - The web interface is usually not a good match for the problem. Email\n   interface is better in many respects, but it still does not cut it.\n - You can't really use the ability of version control to work disconnected,\n   when you don't also have the bug information.\n - Distributed version control is designed to decrease the workload of the\n   central maintainer(s) while keeping him in control. But with centralized\n   bug tracking he still has a lot of work with that that the mob can't help\n   him with. It helps if the bug tracker can close bugs based on something in\n   commit-log, but you also need to see what it is that will be closed, which\n   requires integrating the bug tracker into the version control.\n\nThe other thing is, that a good bug tracker also needs to be integrated with\nthe *mailing list*. The major part of bug tracking is discussing those bugs\nand discussions usually take place on mailing-lists (and on irc --\nintegrating that as well would be nice too).\n\nI've actually already seen some attempts at something like this project. The\nfirst one was for GNU Arch. Instead of using a bug-tracker, there was\na branch where each bug had it's mbox with all the relevant data. This mbox\nwas moved between directories depending on it's state. AFAIR there was no\ntool to maintain it, just a description of the workflow.\n(Tom Lord called it \"the game\". See eg.\nhttp://www.dasbistro.com/~sam/mail/tom-lords-game)\n\nThe other attempt is obviously the Bugs Everywhere thing.\n\nA related thing is Bazaar's \"Bundle Buggy\". It tracks patch submission rather\nthan bugs, but it is roughly what I meant by the \"mailing list integration\"\nabove. It \"reads\" the mailing list, watching for anything labeled [PATCH] or\n[BUNDLE] with patch or bundle (bundle is bazaar's extended patch) attached.\nIt also watches for replies with review (review outcome is stated with \"-1\"\n(veto), \"-0\", \"+0\" and \"+1\" (ok)) and with further patches/bundles (updated\nversions of the patch).\n\n> [...] \n>\n> And definitely, if you use git as an alibi to write a new bugtracker,\n> don't use the \"works only with git\" as a feature. It should work with\n> as many SCMs as possible.\n\nIf it uses git as it's database, which it probably will, it will definitely\nrequire git. Now it should be possible to have the code in different version\ncontrol, but it would be integration with things like git format-patch, that\nwill really make it cool stuff -- and that won't work with other version\ncontrol out of the box.\n\n> OTOH, that's just me, I'm lazy and like to work on already-successful\n> projects that are 99% there for my needs (and where I can add that\n> 1%).\n\nYes. But for many people current bug tracking tools do NOT work 99%.\n\n-- \n\t\t\t\t\t\t Jan 'Bulb' Hudec <bulb@ucw.cz>\n"},{"id":"44550","messageId":"46a038f90706100138g46d872f7o463418631585bf13@mail.gmail.com","threadId":"8409","inReplyTo":"7v4plgb6t6.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFC] git integrated bugtracking","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2007-06-10T08:38:03Z","receivedAt":"2007-06-10T08:38:03Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 6/10/07, Junio C Hamano <gitster@pobox.com> wrote:\n> > Adding git & gitweb support to traq, bugzilla, mantis, gforge, etc is\n> > what is going to make the difference. Most of those have already the\n> > ability to \"link\" to one or more commits -- after the commits are done\n> > and in GIT.\n>\n> You are a brave person to say this (no sarcasm --- I wish I\n> were, too).\n>\n> On one hand, I very much applaud and appreciate your comment for\n> injecting sanity to the discussion.  On the other hand, if Linus\n> had such an attitude, we might not be hacking on git right now.\n\nThanks for the reply - sorry for being a bit of a stirrer ;-) Yes, I\ndo appreciate the irony and I'd have never started git. If anyone\nreally wants to do their own bugtracker... be like Linus not like me\n(a mere follower) ;-)\n\n> After looking at the above existing alternatives, some brave\n> soul might decide and say, \"Hey, I can write something better in\n> 2 weeks\" ;-).\n\nDefinitely. But that takes a deeper look into the above alternatives,\nand probably a good perspective. I hope noone takes offence if I say\nthat -- as a user of several bugtrackers over ~10 years -- I haven't\nyet read anything in this thread that is exciting.\n\nAnd \"it's closely integrated with git\" can actually be a misfeature.\nCool if it's what gets you going, but not enough for world domination\n;-)\n\n> All of your examples are going from a single bug to commits, but\n> from a release person's point of view, you are never interested\n> in a single bug, just like a top-level maintainer is never\n> interested in a single file.  A release person would want to go\n> in the reverse direction: from a commit range to a set of bugs.\n\nThat's right. It's not that hard to correlate commits-in-the-changelog\nand ask the bugtracker to produce a \"tracker changelog\" showing all\nthe bugs/tasks that link to the commits (with that liberal view of\n\"links to\" discussed before). Formatting of the tracker changelog _is_\ntricky but that's due to the ambiguities in those relationships.\n\n(In Moodle I use JIRA, a non-FOSS tracker, and it does exactly that. I\nthink it has some notion of CVS branches, and where tags sit, so you\ncan ask for a report of which bugs are fixed in the release you are\npreparing on branch X).\n\n> What bugs were fixed and what regressions were introduced during\n> this release cycle.  While embedded ticket numbers in commit log\n> messages would certainly help, a change made to fix a particular\n> bug may fix another as its side effect, and the develeoper who\n> did the change may not know about the latter when the commit log\n> message is written.\n\nI agree it's useful, but I don't think it has any benefit having it in\nthe SCM _at all_. Having them in the BT is a lot more flexible -- and\nthe fact that git has stable commit IDs makes it easier to integrate\nin a BT; as the BT can spot that the commit fixing bug 123 is now\nmerged into head ZZ as well as head YYY.\n\nSo the BT holds \"external tags\" to your commits. Lots of them. With a\nton of data. And that's great -- in fact there's no stopping it -- the\nstability of SHA1s means that the whole internet holds tags to your\nrepo. Every time a SHA1 (or output of git-describe) is mentioned in a\nmailing list, wiki or forum, there's a tag.\n\nNow, to rule the world, BTs gain a lot more from being able to\nintegrate with different SCMs, automated test systems (like\ntinderbox), MTAs (debbugs), wikis (traq), stats tracking for PHBs\n(bugzilla), etc. So loose coupling wins here, and git's SHA1s are\ngreat for that.\n\nAnd at git's end we can get the smooth integration using/abusing that\nloose coupling strategy. So if git-log/gitk/qgit grow some hooks that\ncan be used to perform a lookup... I can think of a perl script that\ngets events for each SHA1 that git-rev-list produces and returns one\nbug number, url and title (or more than one) that then git-log / gitk\n/ qgit / annotate can use to further \"decorate\" the commit info in a\nsimilar style to what gitk is doing now with head names in each\ncommit.\n\nWould that fit your vision of a nicely integrated tracker?\n\n\n\nmartin (who's now thinking how to craft a proof of concept)\n"},{"id":"44559","messageId":"20070610085044.GD4084@efreet.light.src","threadId":"8409","inReplyTo":"7v4plgb6t6.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFC] git integrated bugtracking","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2007-06-10T08:50:44Z","receivedAt":"2007-06-10T08:50:44Z","isPatch":false,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"On Sun, Jun 10, 2007 at 00:35:33 -0700, Junio C Hamano wrote:\n> \"Martin Langhoff\" <martin.langhoff@gmail.com> writes:\n> > So you can tell your bugtracker\n> > - which commit fixed it -- usually auto-linked if you include the\n> > bugnumber in the commit message\n> > - which commit added the test -- auto linked as above\n> > - which commit introduced the bug -- if such thing exists and someone\n> > digs it up\n> \n> All of your examples are going from a single bug to commits, but\n> from a release person's point of view, you are never interested\n> in a single bug, just like a top-level maintainer is never\n> interested in a single file.  A release person would want to go\n> in the reverse direction: from a commit range to a set of bugs.\n> What bugs were fixed and what regressions were introduced during\n> this release cycle.  While embedded ticket numbers in commit log\n> messages would certainly help, a change made to fix a particular\n> bug may fix another as its side effect, and the develeoper who\n> did the change may not know about the latter when the commit log\n> message is written.\n\nIt would be really useful to have a tool, that could link a bug report to\na test case demonstrating it and reporting whenever output of that test case\nchanges. This would make it much easier for developer to see which bugs he\nmight have fixed when doing a refactoring.\n\nIt should probably report not just unexpected success, but also change to the\nerror output, because the test case does not have to be 100% correct. That is\nif you have a test case that prints:\n  testFoobar FAIL \"foo\" != \"Bar\"\nand than starts to say:\n  testFoobar FAIL \"foo\" != \"Foo\"\nthe problem is probably fixed, but the test still fails because of minor\nerror in the expected output string.\n\n-- \n\t\t\t\t\t\t Jan 'Bulb' Hudec <bulb@ucw.cz>\n"},{"id":"44561","messageId":"46a038f90706100155q1da663d7le3bf0345c68e47ae@mail.gmail.com","threadId":"8409","inReplyTo":"20070610083754.GC4084@efreet.light.src","subject":"Re: [RFC] git integrated bugtracking","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2007-06-10T08:55:21Z","receivedAt":"2007-06-10T08:55:21Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 6/10/07, Jan Hudec <bulb@ucw.cz> wrote:\n> I don't know about any *distributed* bug tracker, which is the point here.\n\nAs an end user, I suspect I _don't_ want to have to report a bug in a\ndistributed bug tracker ;-) In that space, the Malone guys (canonical)\nhave their fingers on one of the most serious issues, and perhaps it's\ninteresting to see what they've done there. It's really useful, even\nif I don't think I want to have to maintain it :-/\n\n> We have several distributed version control tools, but no other distributed\n> tools for the other tasks in configuration management.\n\nBugtrackers are co-owned by developers, users and (where they exist)\nproject managers.\n\n>  - The web interface is usually not a good match for the problem. Email\n>    interface is better in many respects, but it still does not cut it.\n\nI agree. I love/hate debbugs too.\n\n>  - You can't really use the ability of version control to work disconnected,\n>    when you don't also have the bug information.\n\nA cache fixes the reading part  - see my other post, and imagine being\nable to have a local sqlite cache of the BT key data indexed by\nreferenced SHA1, showing up with your commits in gitk.\n\nThe write part is solved (in part) by committing to git the fix -- if\nyou mentionm the bug ID, the central BT will pick it up when your\ncommit appears in the branches/repos that the BT can see.\n\nFor \"just adding a comment\", the write part is solved by the \"email\"\ninterface, like with debbugs.\n\n>  - Distributed version control is designed to decrease the workload of the\n>    central maintainer(s) while keeping him in control. But with centralized\n\nAnd to provide a single place for users to report a problem and track\nits status.\n\n> If it uses git as it's database, which it probably will,\n\nWell - hmmm. Git's database is great at tracking _content identity_.\nBut a bug's content identity (description+comments+status) changes all\nthe time. I don't think it's naturally a good match.\n\nPerhaps it makes sense to mix git's storage model with something else...?\n\n> Yes. But for many people current bug tracking tools do NOT work 99%.\n\nHmmm. I agree in that \"does not work disconnected\" is a big issue with\nweb tools, but debbugs works disconnected, and is good. Git's\nbugtracker (git@vger) works disconnected too ;-) And googlegears might\nhelp the rest of us. Is there any other problem with current BTs?\n\ncheers,\n\n\nmartin\n"},{"id":"44581","messageId":"20070610101616.GF2951@artemis","threadId":"8409","inReplyTo":"46a038f90706100138g46d872f7o463418631585bf13@mail.gmail.com","subject":"Re: [RFC] git integrated bugtracking","fromName":"Pierre Habouzit","fromEmail":"madcoder@debian.org","sentAt":"2007-06-10T10:16:16Z","receivedAt":"2007-06-10T10:16:16Z","isPatch":false,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":"On Sun, Jun 10, 2007 at 06:59:13PM +1200, Martin Langhoff wrote:\n> On 6/10/07, Pierre Habouzit <madcoder@debian.org> wrote:\n> >  FWIW I've begun to work on this (for real). I've called the tool\n> >\"grit\". You can follow the developpement on:\n> >\n> >  * gitweb: http://git.madism.org/?p=grit.git;a=summary\n> >  * git:    git://git.madism.org/grit.git/\n> \n> Call me a fool, but writing a <new> bugtracker looks like a\n> boil-the-oceans scheme.\n\n  Sure, what if I like it anyway ?\n\n> Adding git & gitweb support to traq, bugzilla, mantis, gforge, etc is\n> what is going to make the difference. Most of those have already the\n> ability to \"link\" to one or more commits -- after the commits are done\n> and in GIT.\n\n  Sure, you can do that and still inherit from the many downsides of\nthose tools: central, needs another separate tool to work with, and a\ntool that nowadays tends to eat 500Mb of your memory if you take the\nmost hype implementation of it (Yes I'm describing a web browser), that\nis slow like hell (because yes, there is many clients at the same time\non the central server, that is overloaded like hell), and so on.\n\n  You can like central web UIs, your choice. And I suppose if grit works\nwell, there will be one at some point.\n\n> So you can tell your bugtracker\n> - which commit fixed it -- usually auto-linked if you include the\n> bugnumber in the commit message\n> - which commit added the test -- auto linked as above\n> - which commit introduced the bug -- if such thing exists and someone\n> digs it up\n\n  yeah, that is what bugtrackers already do. Though, that's of no use\nfor release managers. What is useful is what people call \"milestones\" in\ntrac e.g., meaning a set of bugs that has been flagged as needing to be\nfixed. And what a release manager need is a tool to deal with this set\nof bugs as a whole.\n\n  That's the same argument that Linus has against per-file tracking.\nAlso atm when you e.g. backport a patch that fixes this or this bug,\nyou're no BTS helps you tagging the bug as fixed in that branch as well.\nNot to mention that BTS I know do not make any use of the commits DAG.\nAnd for a very good reason, there is no real DAG in many existing tools\n(svn, cvs, ...).\n\n> If the bugtracker can also auto-link things that look committish in\n> text entered by users (someone might write \"bisect sez that f345e is\n> to blame\"), with tooltips indicating in which heads those commits\n> resides (like gitk does), then it's just gorgeous.\n\n  that's not up to the BTS tool to do that, it's way to high level. It's\nup to the importing filters/hooks that will parse the associated ML, and\nthat would translate that to useful low level BTS commands.\n\n\n> And definitely, if you use git as an alibi to write a new bugtracker,\n> don't use the \"works only with git\" as a feature. It should work with\n> as many SCMs as possible.\n\n  No it should not, because it can't. I want the distributed and\nBug status spanning-DAGS be a central feature. So that means that this\ntool can only work on top of SCMs that support that. ttbomk git, hg,\n_maybe_ bzr fit the description. I only know the former, but I really\nplan to write the tool in a way that the underlying SCM does not matters\n_too_ much. Maybe I'll fail. Honestly, I don't really care (yet ?).\n\n\n\n> OTOH, that's just me, I'm lazy and like to work on already-successful\n> projects that are 99% there for my needs (and where I can add that\n> 1%).\n\n  You're a lucky guy. All bug trackers I've used suck a way or another,\nthat impedes my workflow a lot. Let's cite a couple:\n  * bugzilla: takes more from the -zilla than from the BTS side. It's\n    huge, monstruous, slow (have ever used glibc's bugzilla ? it has\n    maybe 5k bugs, it's slow like if it ran on an Atari ST), complex,\n    the mail gateway suck hard, it's completely unusable for me. Believe\n    me, I've packaged KDE for 2 years in Debian, now am in the glibc\n    team. Every single day I have to work on this horrible tool is a\n    PITA.\n\n  * flyspray: I've been upstream for a short time. Visually nice, good\n    to work with, UI is great. Integration totally suck, worthless.\n    Can't use mails either, needs a Web Browser -> useless. The same\n    holds for mantis, roundup and a lot of other friends.\n\n  * debbugs: oh yeah there is a mail interface. So slow that you have to\n    wait up to 15 minutes to see your command be taken into account. And\n    when you have to deal with dozens of bugs (Yes I've done that on a\n    regular basis) you _have_ sometimes to wait for the answer to come\n    back (because you need an ID that will be in there e.g.) to continue\n    your work. That is unacceptable, you pass most of your time waiting.\n    Moreover sometimes you made an error in your commands, so you also\n    need to parse the anwer ... one day later because \"immediateley when\n    you still remembered what this was about\" is not an option.\n    Unacceptable again. The plus: it uses mboxes, hence is worthwile in\n    a hacking environment, it fits the workflow well.\n\n  * trac: very very very nice tool. I mean it. We use it at work, where\n    I have to suffer svn (through git-svn though). It's really nice (did\n    I repeat myself ?). THough, it's on top of svn, and you can't use\n    the Bugs informations from your repository. You can't say: I'm\n    backporting that patch into that branch. Now what affects this\n    branch please ? Trac can't answer that (and ttbomk now BTS really\n    can anyway, except Debian's debbugs instance, and it's somehow\n    limited). That is a question a release manager takes 80% of his time\n    to ask. I hope grit can take back to the 0.01% of his time, which is\n    still too much.\n\n\nOn Sun, Jun 10, 2007 at 08:55:21PM +1200, Martin Langhoff wrote:\n> On 6/10/07, Jan Hudec <bulb@ucw.cz> wrote:\n> >I don't know about any *distributed* bug tracker, which is the point \n> >here.\n> \n> As an end user, I suspect I _don't_ want to have to report a bug in a\n> distributed bug tracker ;-)\n\n  I trol^Wdiscuss everyday on debian's channel with friends that tell\nthat svn is the best tool ever, and that they would never ever use a\ndistributed SCM because it's too hard to understand. Your call.\n\n> > We have several distributed version control tools, but no other\n> > distributed tools for the other tasks in configuration management.\n>\n> Bugtrackers are co-owned by developers, users and (where they exist)\n> project managers.\n\n  That's exactly why distributed rock. Because everyone could _really_\nown _his_ bugtracker. This solves the same range of ACLish issues git\nsolves with respect to the code.\n\n> > - Distributed version control is designed to decrease the workload of\n> >   the central maintainer(s) while keeping him in control. But with\n> >   centralized\n>\n> And to provide a single place for users to report a problem and track\n> its status.\n\n  Why wouldn't it exist a \"public reporting interface\"-branch ? that\nwould be the same purpose as the mainline ~linus/linux2.6.git tree. And\nyou can build/instanciate your beloved web UI on top of that, and people\nwould just have to pull from there. What a shock, it's easy !\n\n> > If it uses git as it's database, which it probably will,\n>\n> Well - hmmm. Git's database is great at tracking _content identity_.\n> But a bug's content identity (description+comments+status) changes all\n> the time. I don't think it's naturally a good match.\n\n  Oh, because the code never changes. Doh, how stupid I am :)\n  No, really, you name your bug after the sha hash of the first report,\nI think that's pretty obvious. That gives you a bug name. Then you ask\ngit for \"what's the current sha for this bug in the tip of the BTS\nbranch\", then you ask \"so now what this new sha is pointing to in the\ncode\". That's a small indirection that I suppose is bearable.\n\n> > Yes. But for many people current bug tracking tools do NOT work 99%.\n>\n> Hmmm. I agree in that \"does not work disconnected\" is a big issue with\n> web tools, but debbugs works disconnected, and is good. Git's\n> bugtracker (git@vger) works disconnected too ;-) And googlegears might\n> help the rest of us. Is there any other problem with current BTs?\n\n  It's not integrated with the workflow. And sorry, but git@vger (or\nworkse lkml@vger).. it does not work. Maybe for git it does because the\nflow is still human manageable, and that it seems junio has enough time\nfor it. But for the kernel ? please. You should read Bastian Blank\nfrustration about regressions and nobody tracking them. Know why ?\nbecause there is no tool that is well known and well integrated in the\nworkflow. There is a long rant against kernel.org's bugzilla, you should\nread it as well. It's not really instructive (at least there wasn't\nanything new for me in it, I was already bought to many arguments in\nthere). But you'll see the world isn't as rosa-lila you think it is.\n\n\nOn Sun, Jun 10, 2007 at 08:38:03PM +1200, Martin Langhoff wrote:\n> On 6/10/07, Junio C Hamano <gitster@pobox.com> wrote:\n> > After looking at the above existing alternatives, some brave soul\n> > might decide and say, \"Hey, I can write something better in 2 weeks\"\n> > ;-).\n\n  I'm sure I could come up with something really better in say a\nmonth... If I hadn't paid work to do too :)\n\n> And \"it's closely integrated with git\" can actually be a misfeature.\n> Cool if it's what gets you going, but not enough for world domination\n> ;-)\n\n  It's a misfeature for you because you read it as \"non portable\".\nThat's a fair point. And like said, it may be extended to SCM's with the\nsame set of features I need to build it. But let's be honnest, I don't\ncare about a BTS that uses the smallest common set of features of SCM's.\nReading this list, you should know it's almost a void set. No, I think a\ngood BTS should make an excellent use of high level features of the SCM.\nThe real problem is, there is maybe 2 or 3 SCMs that have this set of\nstrong and good features. Too bad for the other, I can't work with them,\nthey suck hard, and I don't see why I should support bad practices\nanyways.\n\n  (Yes I'm also a guy with strong opinions too, it's not really\nrestricted to Linus ;p)\n\n> I agree it's useful, but I don't think it has any benefit having it in\n> the SCM _at all_. Having them in the BT is a lot more flexible -- and\n> the fact that git has stable commit IDs makes it easier to integrate\n> in a BT; as the BT can spot that the commit fixing bug 123 is now\n> merged into head ZZ as well as head YYY.\n\n  If you do that you loose:\n  * fastness, and I don't want to work with debbugs anymore.\n\n  * distribution: Meaning that for _one_ project everybody needs to use\n    this central bugtracker. Whereas .oO(kernel) there is some projects\n    where the subcomponents are dealt with from very different teams,\n    very different way to release things, and they are interested with\n    their bugs, and their bugs only. They would prefer a very fast\n    interface to deal with their 1k bugs, and not worry about the 100k\n    the rest of the project has.\n    Branching bugs also makes sense you know ?\n\n> Now, to rule the world, BTs gain a lot more from being able to\n> integrate with different SCMs,\n\n  You are the one saying it. I beg to differ.\n\n> automated test systems (like tinderbox), MTAs (debbugs), wikis (traq),\n> stats tracking for PHBs (bugzilla), etc. So loose coupling wins here,\n> and git's SHA1s are great for that.\n\n  IMHO a BTS is a _low_ level tool. that's the road git took, I\nsometimes describe the plumbing git commands as the \"Assembler\" of the\nSCM world to friends when I talk to them about git. That's really the\nbest way to implement a thing: have a small small set of rock solid,\nwell designed tools, and build the others as porcelains with them.\n\n  Testing is a high level tool. I don't need to support them, I need to\nhave exactly the low level querying rocket-fast query interfaces so that\nintegration scripts are at most 100 lines long.\n\n> And at git's end we can get the smooth integration using/abusing that\n> loose coupling strategy. So if git-log/gitk/qgit grow some hooks that\n> can be used to perform a lookup... I can think of a perl script that\n> gets events for each SHA1 that git-rev-list produces and returns one\n> bug number, url and title (or more than one) that then git-log / gitk\n> / qgit / annotate can use to further \"decorate\" the commit info in a\n> similar style to what gitk is doing now with head names in each\n> commit.\n> \n> Would that fit your vision of a nicely integrated tracker?\n\n  Honestly ? No, because that would be horribly slow (but I'd love to be\nproven wrong).\n\n\nCheers,\n-- \n·O·  Pierre Habouzit\n··O                                                madcoder@debian.org\nOOO                                                http://www.madism.org\n"},{"id":"44582","messageId":"20070610104901.GE4084@efreet.light.src","threadId":"8409","inReplyTo":"46a038f90706100155q1da663d7le3bf0345c68e47ae@mail.gmail.com","subject":"Re: [RFC] git integrated bugtracking","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2007-06-10T10:49:01Z","receivedAt":"2007-06-10T10:49:01Z","isPatch":false,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"On Sun, Jun 10, 2007 at 20:55:21 +1200, Martin Langhoff wrote:\n> On 6/10/07, Jan Hudec <bulb@ucw.cz> wrote:\n> >I don't know about any *distributed* bug tracker, which is the point here.\n> \n> As an end user, I suspect I _don't_ want to have to report a bug in a\n> distributed bug tracker ;-)\n\nAs an end user, you would just post the bug report to a mailing list. The bug\ntracker would take care of adding it to the \"master repository\".\n\n> In that space, the Malone guys (canonical)\n> have their fingers on one of the most serious issues, and perhaps it's\n> interesting to see what they've done there. It's really useful, even\n> if I don't think I want to have to maintain it :-/\n\nI don't think they even have a mail interface. You have to register to post\na bug, just as with most of the crappy web-based bug trackers out there.\n\nThey have some nice integration with bazaar, but AFAIK the branch has to be\nmirrored on launchpad, to which the whole thing is really tied too much.\nAlso I can find download link anywhere there, nor anywhere they'd state it's\nlicense (and from what I heard it is NOT open-source).\n\nSo while they might have some nice features, it's not that suitable for\ngeneral public.\n\n> >We have several distributed version control tools, but no other distributed\n> >tools for the other tasks in configuration management.\n> \n> Bugtrackers are co-owned by developers, users and (where they exist)\n> project managers.\n\nI agree that branches don't make that much sense in bug trackers. Except in\nrare cases like when the project is forked or such. The bug tracker is there\nso the people stay in sync. However I think trying to design a distributed\nbug tracker can bring useful insignts into the problems involved.\n\n> > - The web interface is usually not a good match for the problem. Email\n> >   interface is better in many respects, but it still does not cut it.\n> \n> I agree. I love/hate debbugs too.\n\n... there's a related issue of what the mail user agents can do. If my mail\nclient was really good as personal task manager, mail-based bug trackers\nwould work quite well. But the MUAs are not all that good.\n\n> > - You can't really use the ability of version control to work \n> > disconnected,\n> >   when you don't also have the bug information.\n> \n> A cache fixes the reading part  - see my other post, and imagine being\n> able to have a local sqlite cache of the BT key data indexed by\n> referenced SHA1, showing up with your commits in gitk.\n> \n> The write part is solved (in part) by committing to git the fix -- if\n> you mentionm the bug ID, the central BT will pick it up when your\n> commit appears in the branches/repos that the BT can see.\n> \n> For \"just adding a comment\", the write part is solved by the \"email\"\n> interface, like with debbugs.\n> \n> > - Distributed version control is designed to decrease the workload of the\n> >   central maintainer(s) while keeping him in control. But with centralized\n> \n> And to provide a single place for users to report a problem and track\n> its status.\n\nJust like there is the \"master\" repository, there would be the \"master\" bug\ntracker.\n\n> >If it uses git as it's database, which it probably will,\n> \n> Well - hmmm. Git's database is great at tracking _content identity_.\n> But a bug's content identity (description+comments+status) changes all\n> the time. I don't think it's naturally a good match.\n> \n> Perhaps it makes sense to mix git's storage model with something else...?\n\nYou are right here. Git can be used to store the data bits, but they need to\nbe glued together somehow (with tags or something). So we can as well store\nthem in some other kind of database and it might be even better.\n\n> >Yes. But for many people current bug tracking tools do NOT work 99%.\n> \n> Hmmm. I agree in that \"does not work disconnected\" is a big issue with\n> web tools, but debbugs works disconnected, and is good. Git's\n> bugtracker (git@vger) works disconnected too ;-) And googlegears might\n> help the rest of us. Is there any other problem with current BTs?\n\nWell, there is no BT that would satisfy all the points above ;-). Debbugs has\na good email interface, but it's a huge beast and tied with the Debian\narchive logic quite a lot. The rest -- except maybe gnats (I'll have to look\nat that -- it looks interesting) -- does not seem to have much sensible email\nsupport.\n\nFollowing up on the note about MUAs above, one interesting idea to create\na bug tracker (that would not be git specific nor actually use git for\nanything) would be to:\n - Create a mailing list bot, that would watch for bug reports either on\n   dedicated address or by watching for [BUG] or something, and replies to\n   them.\n - Export the bug database via read-only imap (or pop3 or webdav). There are\n   already tools to create local cache for such protocols, which would\n   resolve the disconnected issue and give good query speed, because the data\n   would be local.\n - The server would make sure that all the messages applying to a particular\n   issue are correctly linked with In-Reply-To: headers to form a single\n   thread.\n - Status of the bug could be expressed with mailbox it is in (backwards\n   compatible way) or some kind of tags (which would need to be supported by\n   the mail client -- I really think it's about time for something like\n   that).\n - Other metainformation about the bug could be added as a special message\n   inserted at the begining of the thread, or added into the first message\n - Than support for todo management could be improved in some mail clients.\n   It is not precondition for this kind of bug tracking to be useful and on\n   the other hand would be useful on it's own.\n - It could even be done as another interface to an existing web-based BT,\n   though I would prefer if the web interface would not have to be running\n   then.\n\n-- \n\t\t\t\t\t\t Jan 'Bulb' Hudec <bulb@ucw.cz>\n"},{"id":"44600","messageId":"20070610133457.GB24869@artemis","threadId":"8409","inReplyTo":"46a038f90706092359i43a6e834rc096e53a28fbee51@mail.gmail.com","subject":"Re: [RFC] git integrated bugtracking","fromName":"Pierre Habouzit","fromEmail":"madcoder@debian.org","sentAt":"2007-06-10T13:34:57Z","receivedAt":"2007-06-10T13:34:57Z","isPatch":false,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":"On Sun, Jun 10, 2007 at 06:59:13PM +1200, Martin Langhoff wrote:\n> On 6/10/07, Pierre Habouzit <madcoder@debian.org> wrote:\n> >  FWIW I've begun to work on this (for real). I've called the tool\n> >\"grit\". You can follow the developpement on:\n> >\n> >  * gitweb: http://git.madism.org/?p=grit.git;a=summary\n> >  * git:    git://git.madism.org/grit.git/\n>\n> Call me a fool, but writing a <new> bugtracker looks like a\n> boil-the-oceans scheme.\n\n  Sure, what if I like it anyway ?\n\n> Adding git & gitweb support to traq, bugzilla, mantis, gforge, etc is\n> what is going to make the difference. Most of those have already the\n> ability to \"link\" to one or more commits -- after the commits are done\n> and in GIT.\n\n  Sure, you can do that and still inherit from the many downsides of\nthose tools: central, needs another separate tool to work with, and a\ntool that nowadays tends to eat 500Mb of your memory if you take the\nmost hype implementation of it (Yes I'm describing a web browser), that\nis slow like hell (because yes, there is many clients at the same time\non the central server, that is overloaded like hell), and so on.\n\n  You can like central web UIs, your choice. And I suppose if grit works\nwell, there will be one at some point.\n\n> So you can tell your bugtracker\n> - which commit fixed it -- usually auto-linked if you include the\n> bugnumber in the commit message\n> - which commit added the test -- auto linked as above\n> - which commit introduced the bug -- if such thing exists and someone\n> digs it up\n\n  yeah, that is what bugtrackers already do. Though, that's of no use\nfor release managers. What is useful is what people call \"milestones\" in\ntrac e.g., meaning a set of bugs that has been flagged as needing to be\nfixed. And what a release manager need is a tool to deal with this set\nof bugs as a whole.\n\n  That's the same argument that Linus has against per-file tracking.\nAlso atm when you e.g. backport a patch that fixes this or this bug,\nyou're no BTS helps you tagging the bug as fixed in that branch as well.\nNot to mention that BTS I know do not make any use of the commits DAG.\nAnd for a very good reason, there is no real DAG in many existing tools\n(svn, cvs, ...).\n\n> If the bugtracker can also auto-link things that look committish in\n> text entered by users (someone might write \"bisect sez that f345e is\n> to blame\"), with tooltips indicating in which heads those commits\n> resides (like gitk does), then it's just gorgeous.\n\n  that's not up to the BTS tool to do that, it's way to high level. It's\nup to the importing filters/hooks that will parse the associated ML, and\nthat would translate that to useful low level BTS commands.\n\n\n> And definitely, if you use git as an alibi to write a new bugtracker,\n> don't use the \"works only with git\" as a feature. It should work with\n> as many SCMs as possible.\n\n  No it should not, because it can't. I want the distributed and\nBug status spanning-DAGS be a central feature. So that means that this\ntool can only work on top of SCMs that support that. ttbomk git, hg,\n_maybe_ bzr fit the description. I only know the former, but I really\nplan to write the tool in a way that the underlying SCM does not matters\n_too_ much. Maybe I'll fail. Honestly, I don't really care (yet ?).\n\n\n\n> OTOH, that's just me, I'm lazy and like to work on already-successful\n> projects that are 99% there for my needs (and where I can add that\n> 1%).\n\n  You're a lucky guy. All bug trackers I've used suck a way or another,\nthat impedes my workflow a lot. Let's cite a couple:\n  * bugzilla: takes more from the -zilla than from the BTS side. It's\n    huge, monstruous, slow (have ever used glibc's bugzilla ? it has\n    maybe 5k bugs, it's slow like if it ran on an Atari ST), complex,\n    the mail gateway suck hard, it's completely unusable for me. Believe\n    me, I've packaged KDE for 2 years in Debian, now am in the glibc\n    team. Every single day I have to work on this horrible tool is a\n    PITA.\n\n  * flyspray: I've been upstream for a short time. Visually nice, good\n    to work with, UI is great. Integration totally suck, worthless.\n    Can't use mails either, needs a Web Browser -> useless. The same\n    holds for mantis, roundup and a lot of other friends.\n\n  * debbugs: oh yeah there is a mail interface. So slow that you have to\n    wait up to 15 minutes to see your command be taken into account. And\n    when you have to deal with dozens of bugs (Yes I've done that on a\n    regular basis) you _have_ sometimes to wait for the answer to come\n    back (because you need an ID that will be in there e.g.) to continue\n    your work. That is unacceptable, you pass most of your time waiting.\n    Moreover sometimes you made an error in your commands, so you also\n    need to parse the anwer ... one day later because \"immediateley when\n    you still remembered what this was about\" is not an option.\n    Unacceptable again. The plus: it uses mboxes, hence is worthwile in\n    a hacking environment, it fits the workflow well.\n\n  * trac: very very very nice tool. I mean it. We use it at work, where\n    I have to suffer svn (through git-svn though). It's really nice (did\n    I repeat myself ?). THough, it's on top of svn, and you can't use\n    the Bugs informations from your repository. You can't say: I'm\n    backporting that patch into that branch. Now what affects this\n    branch please ? Trac can't answer that (and ttbomk now BTS really\n    can anyway, except Debian's debbugs instance, and it's somehow\n    limited). That is a question a release manager takes 80% of his time\n    to ask. I hope grit can take back to the 0.01% of his time, which is\n    still too much.\n\n\nOn Sun, Jun 10, 2007 at 08:55:21PM +1200, Martin Langhoff wrote:\n> On 6/10/07, Jan Hudec <bulb@ucw.cz> wrote:\n> >I don't know about any *distributed* bug tracker, which is the point\n> >here.\n>\n> As an end user, I suspect I _don't_ want to have to report a bug in a\n> distributed bug tracker ;-)\n\n  I trol^Wdiscuss everyday on debian's channel with friends that tell\nthat svn is the best tool ever, and that they would never ever use a\ndistributed SCM because it's too hard to understand. Your call.\n\n> > We have several distributed version control tools, but no other\n> > distributed tools for the other tasks in configuration management.\n>\n> Bugtrackers are co-owned by developers, users and (where they exist)\n> project managers.\n\n  That's exactly why distributed rock. Because everyone could _really_\nown _his_ bugtracker. This solves the same range of ACLish issues git\nsolves with respect to the code.\n\n> > - Distributed version control is designed to decrease the workload of\n> >   the central maintainer(s) while keeping him in control. But with\n> >   centralized\n>\n> And to provide a single place for users to report a problem and track\n> its status.\n\n  Why wouldn't it exist a \"public reporting interface\"-branch ? that\nwould be the same purpose as the mainline ~linus/linux2.6.git tree. And\nyou can build/instanciate your beloved web UI on top of that, and people\nwould just have to pull from there. What a shock, it's easy !\n\n> > If it uses git as it's database, which it probably will,\n>\n> Well - hmmm. Git's database is great at tracking _content identity_.\n> But a bug's content identity (description+comments+status) changes all\n> the time. I don't think it's naturally a good match.\n\n  Oh, because the code never changes. Doh, how stupid I am :)\n  No, really, you name your bug after the sha hash of the first report,\nI think that's pretty obvious. That gives you a bug name. Then you ask\ngit for \"what's the current sha for this bug in the tip of the BTS\nbranch\", then you ask \"so now what this new sha is pointing to in the\ncode\". That's a small indirection that I suppose is bearable.\n\n> > Yes. But for many people current bug tracking tools do NOT work 99%.\n>\n> Hmmm. I agree in that \"does not work disconnected\" is a big issue with\n> web tools, but debbugs works disconnected, and is good. Git's\n> bugtracker (git@vger) works disconnected too ;-) And googlegears might\n> help the rest of us. Is there any other problem with current BTs?\n\n  It's not integrated with the workflow. And sorry, but git@vger (or\nworkse lkml@vger).. it does not work. Maybe for git it does because the\nflow is still human manageable, and that it seems junio has enough time\nfor it. But for the kernel ? please. You should read Bastian Blank\nfrustration about regressions and nobody tracking them. Know why ?\nbecause there is no tool that is well known and well integrated in the\nworkflow. There is a long rant against kernel.org's bugzilla, you should\nread it as well. It's not really instructive (at least there wasn't\nanything new for me in it, I was already bought to many arguments in\nthere). But you'll see the world isn't as rosa-lila you think it is.\n\n\nOn Sun, Jun 10, 2007 at 08:38:03PM +1200, Martin Langhoff wrote:\n> On 6/10/07, Junio C Hamano <gitster@pobox.com> wrote:\n> > After looking at the above existing alternatives, some brave soul\n> > might decide and say, \"Hey, I can write something better in 2 weeks\"\n> > ;-).\n\n  I'm sure I could come up with something really better in say a\nmonth... If I hadn't paid work to do too :)\n\n> And \"it's closely integrated with git\" can actually be a misfeature.\n> Cool if it's what gets you going, but not enough for world domination\n> ;-)\n\n  It's a misfeature for you because you read it as \"non portable\".\nThat's a fair point. And like said, it may be extended to SCM's with the\nsame set of features I need to build it. But let's be honnest, I don't\ncare about a BTS that uses the smallest common set of features of SCM's.\nReading this list, you should know it's almost a void set. No, I think a\ngood BTS should make an excellent use of high level features of the SCM.\nThe real problem is, there is maybe 2 or 3 SCMs that have this set of\nstrong and good features. Too bad for the other, I can't work with them,\nthey suck hard, and I don't see why I should support bad practices\nanyways.\n\n  (Yes I'm also a guy with strong opinions too, it's not really\nrestricted to Linus ;p)\n\n> I agree it's useful, but I don't think it has any benefit having it in\n> the SCM _at all_. Having them in the BT is a lot more flexible -- and\n> the fact that git has stable commit IDs makes it easier to integrate\n> in a BT; as the BT can spot that the commit fixing bug 123 is now\n> merged into head ZZ as well as head YYY.\n\n  If you do that you loose:\n  * fastness, and I don't want to work with debbugs anymore.\n\n  * distribution: Meaning that for _one_ project everybody needs to use\n    this central bugtracker. Whereas .oO(kernel) there is some projects\n    where the subcomponents are dealt with from very different teams,\n    very different way to release things, and they are interested with\n    their bugs, and their bugs only. They would prefer a very fast\n    interface to deal with their 1k bugs, and not worry about the 100k\n    the rest of the project has.\n    Branching bugs also makes sense you know ?\n\n> Now, to rule the world, BTs gain a lot more from being able to\n> integrate with different SCMs,\n\n  You are the one saying it. I beg to differ.\n\n> automated test systems (like tinderbox), MTAs (debbugs), wikis (traq),\n> stats tracking for PHBs (bugzilla), etc. So loose coupling wins here,\n> and git's SHA1s are great for that.\n\n  IMHO a BTS is a _low_ level tool. that's the road git took, I\nsometimes describe the plumbing git commands as the \"Assembler\" of the\nSCM world to friends when I talk to them about git. That's really the\nbest way to implement a thing: have a small small set of rock solid,\nwell designed tools, and build the others as porcelains with them.\n\n  Testing is a high level tool. I don't need to support them, I need to\nhave exactly the low level querying rocket-fast query interfaces so that\nintegration scripts are at most 100 lines long.\n\n> And at git's end we can get the smooth integration using/abusing that\n> loose coupling strategy. So if git-log/gitk/qgit grow some hooks that\n> can be used to perform a lookup... I can think of a perl script that\n> gets events for each SHA1 that git-rev-list produces and returns one\n> bug number, url and title (or more than one) that then git-log / gitk\n> / qgit / annotate can use to further \"decorate\" the commit info in a\n> similar style to what gitk is doing now with head names in each\n> commit.\n>\n> Would that fit your vision of a nicely integrated tracker?\n\n  Honestly ? No, because that would be horribly slow (but I'd love to be\nproven wrong).\n\n\nCheers,\n\n-- \n·O·  Pierre Habouzit\n··O                                                madcoder@debian.org\nOOO                                                http://www.madism.org\n"},{"id":"44604","messageId":"20070610134358.GC24869@artemis","threadId":"8409","inReplyTo":"46a038f90706092359i43a6e834rc096e53a28fbee51@mail.gmail.com","subject":"Re: [RFC] git integrated bugtracking","fromName":"Pierre Habouzit","fromEmail":"madcoder@debian.org","sentAt":"2007-06-10T13:43:59Z","receivedAt":"2007-06-10T13:43:59Z","isPatch":false,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":"On Sun, Jun 10, 2007 at 06:59:13PM +1200, Martin Langhoff wrote:\n> On 6/10/07, Pierre Habouzit <madcoder@debian.org> wrote:\n> >  FWIW I've begun to work on this (for real). I've called the tool\n> >\"grit\". You can follow the developpement on:\n> >\n> >  * gitweb: http://git.madism.org/?p=grit.git;a=summary\n> >  * git:    git://git.madism.org/grit.git/\n>\n> Call me a fool, but writing a <new> bugtracker looks like a\n> boil-the-oceans scheme.\n\n  Sure, what if I like it anyway ?\n\n> Adding git & gitweb support to traq, bugzilla, mantis, gforge, etc is\n> what is going to make the difference. Most of those have already the\n> ability to \"link\" to one or more commits -- after the commits are done\n> and in GIT.\n\n  Sure, you can do that and still inherit from the many downsides of\nthose tools: central, needs another separate tool to work with, and a\ntool that nowadays tends to eat 500Mb of your memory if you take the\nmost hype implementation of it (Yes I'm describing a web browser), that\nis slow like hell (because yes, there is many clients at the same time\non the central server, that is overloaded like hell), and so on.\n\n  You can like central web UIs, your choice. And I suppose if grit works\nwell, there will be one at some point.\n\n> So you can tell your bugtracker\n> - which commit fixed it -- usually auto-linked if you include the\n> bugnumber in the commit message\n> - which commit added the test -- auto linked as above\n> - which commit introduced the bug -- if such thing exists and someone\n> digs it up\n\n  yeah, that is what bugtrackers already do. Though, that's of no use\nfor release managers. What is useful is what people call \"milestones\" in\ntrac e.g., meaning a set of bugs that has been flagged as needing to be\nfixed. And what a release manager need is a tool to deal with this set\nof bugs as a whole.\n\n  That's the same argument that Linus has against per-file tracking.\nAlso atm when you e.g. backport a patch that fixes this or this bug,\nyou're no BTS helps you tagging the bug as fixed in that branch as well.\nNot to mention that BTS I know do not make any use of the commits DAG.\nAnd for a very good reason, there is no real DAG in many existing tools\n(svn, cvs, ...).\n\n> If the bugtracker can also auto-link things that look committish in\n> text entered by users (someone might write \"bisect sez that f345e is\n> to blame\"), with tooltips indicating in which heads those commits\n> resides (like gitk does), then it's just gorgeous.\n\n  that's not up to the BTS tool to do that, it's way to high level. It's\nup to the importing filters/hooks that will parse the associated ML, and\nthat would translate that to useful low level BTS commands.\n\n\n> And definitely, if you use git as an alibi to write a new bugtracker,\n> don't use the \"works only with git\" as a feature. It should work with\n> as many SCMs as possible.\n\n  No it should not, because it can't. I want the distributed and\nBug status spanning-DAGS be a central feature. So that means that this\ntool can only work on top of SCMs that support that. ttbomk git, hg,\n_maybe_ bzr fit the description. I only know the former, but I really\nplan to write the tool in a way that the underlying SCM does not matters\n_too_ much. Maybe I'll fail. Honestly, I don't really care (yet ?).\n\n\n\n> OTOH, that's just me, I'm lazy and like to work on already-successful\n> projects that are 99% there for my needs (and where I can add that\n> 1%).\n\n  You're a lucky guy. All bug trackers I've used suck a way or another,\nthat impedes my workflow a lot. Let's cite a couple:\n  * bugzilla: takes more from the -zilla than from the BTS side. It's\n    huge, monstruous, slow (have ever used glibc's bugzilla ? it has\n    maybe 5k bugs, it's slow like if it ran on an Atari ST), complex,\n    the mail gateway suck hard, it's completely unusable for me. Believe\n    me, I've packaged KDE for 2 years in Debian, now am in the glibc\n    team. Every single day I have to work on this horrible tool is a\n    PITA.\n\n  * flyspray: I've been upstream for a short time. Visually nice, good\n    to work with, UI is great. Integration totally suck, worthless.\n    Can't use mails either, needs a Web Browser -> useless. The same\n    holds for mantis, roundup and a lot of other friends.\n\n  * debbugs: oh yeah there is a mail interface. So slow that you have to\n    wait up to 15 minutes to see your command be taken into account. And\n    when you have to deal with dozens of bugs (Yes I've done that on a\n    regular basis) you _have_ sometimes to wait for the answer to come\n    back (because you need an ID that will be in there e.g.) to continue\n    your work. That is unacceptable, you pass most of your time waiting.\n    Moreover sometimes you made an error in your commands, so you also\n    need to parse the anwer ... one day later because \"immediateley when\n    you still remembered what this was about\" is not an option.\n    Unacceptable again. The plus: it uses mboxes, hence is worthwile in\n    a hacking environment, it fits the workflow well.\n\n  * trac: very very very nice tool. I mean it. We use it at work, where\n    I have to suffer svn (through git-svn though). It's really nice (did\n    I repeat myself ?). THough, it's on top of svn, and you can't use\n    the Bugs informations from your repository. You can't say: I'm\n    backporting that patch into that branch. Now what affects this\n    branch please ? Trac can't answer that (and ttbomk now BTS really\n    can anyway, except Debian's debbugs instance, and it's somehow\n    limited). That is a question a release manager takes 80% of his time\n    to ask. I hope grit can take back to the 0.01% of his time, which is\n    still too much.\n\n\nOn Sun, Jun 10, 2007 at 08:55:21PM +1200, Martin Langhoff wrote:\n> On 6/10/07, Jan Hudec <bulb@ucw.cz> wrote:\n> >I don't know about any *distributed* bug tracker, which is the point\n> >here.\n>\n> As an end user, I suspect I _don't_ want to have to report a bug in a\n> distributed bug tracker ;-)\n\n  I trol^Wdiscuss everyday on debian's channel with friends that tell\nthat svn is the best tool ever, and that they would never ever use a\ndistributed SCM because it's too hard to understand. Your call.\n\n> > We have several distributed version control tools, but no other\n> > distributed tools for the other tasks in configuration management.\n>\n> Bugtrackers are co-owned by developers, users and (where they exist)\n> project managers.\n\n  That's exactly why distributed rock. Because everyone could _really_\nown _his_ bugtracker. This solves the same range of ACLish issues git\nsolves with respect to the code.\n\n> > - Distributed version control is designed to decrease the workload of\n> >   the central maintainer(s) while keeping him in control. But with\n> >   centralized\n>\n> And to provide a single place for users to report a problem and track\n> its status.\n\n  Why wouldn't it exist a \"public reporting interface\"-branch ? that\nwould be the same purpose as the mainline ~linus/linux2.6.git tree. And\nyou can build/instanciate your beloved web UI on top of that, and people\nwould just have to pull from there. What a shock, it's easy !\n\n> > If it uses git as it's database, which it probably will,\n>\n> Well - hmmm. Git's database is great at tracking _content identity_.\n> But a bug's content identity (description+comments+status) changes all\n> the time. I don't think it's naturally a good match.\n\n  Oh, because the code never changes. Doh, how stupid I am :)\n  No, really, you name your bug after the sha hash of the first report,\nI think that's pretty obvious. That gives you a bug name. Then you ask\ngit for \"what's the current sha for this bug in the tip of the BTS\nbranch\", then you ask \"so now what this new sha is pointing to in the\ncode\". That's a small indirection that I suppose is bearable.\n\n> > Yes. But for many people current bug tracking tools do NOT work 99%.\n>\n> Hmmm. I agree in that \"does not work disconnected\" is a big issue with\n> web tools, but debbugs works disconnected, and is good. Git's\n> bugtracker (git@vger) works disconnected too ;-) And googlegears might\n> help the rest of us. Is there any other problem with current BTs?\n\n  It's not integrated with the workflow. And sorry, but git@vger (or\nworkse lkml@vger).. it does not work. Maybe for git it does because the\nflow is still human manageable, and that it seems junio has enough time\nfor it. But for the kernel ? please. You should read Bastian Blank\nfrustration about regressions and nobody tracking them. Know why ?\nbecause there is no tool that is well known and well integrated in the\nworkflow. There is a long rant against kernel.org's bugzilla, you should\nread it as well. It's not really instructive (at least there wasn't\nanything new for me in it, I was already bought to many arguments in\nthere). But you'll see the world isn't as rosa-lila you think it is.\n\n\nOn Sun, Jun 10, 2007 at 08:38:03PM +1200, Martin Langhoff wrote:\n> On 6/10/07, Junio C Hamano <gitster@pobox.com> wrote:\n> > After looking at the above existing alternatives, some brave soul\n> > might decide and say, \"Hey, I can write something better in 2 weeks\"\n> > ;-).\n\n  I'm sure I could come up with something really better in say a\nmonth... If I hadn't paid work to do too :)\n\n> And \"it's closely integrated with git\" can actually be a misfeature.\n> Cool if it's what gets you going, but not enough for world domination\n> ;-)\n\n  It's a misfeature for you because you read it as \"non portable\".\nThat's a fair point. And like said, it may be extended to SCM's with the\nsame set of features I need to build it. But let's be honnest, I don't\ncare about a BTS that uses the smallest common set of features of SCM's.\nReading this list, you should know it's almost a void set. No, I think a\ngood BTS should make an excellent use of high level features of the SCM.\nThe real problem is, there is maybe 2 or 3 SCMs that have this set of\nstrong and good features. Too bad for the other, I can't work with them,\nthey suck hard, and I don't see why I should support bad practices\nanyways.\n\n  (Yes I'm also a guy with strong opinions too, it's not really\nrestricted to Linus ;p)\n\n> I agree it's useful, but I don't think it has any benefit having it in\n> the SCM _at all_. Having them in the BT is a lot more flexible -- and\n> the fact that git has stable commit IDs makes it easier to integrate\n> in a BT; as the BT can spot that the commit fixing bug 123 is now\n> merged into head ZZ as well as head YYY.\n\n  If you do that you loose:\n  * fastness, and I don't want to work with debbugs anymore.\n\n  * distribution: Meaning that for _one_ project everybody needs to use\n    this central bugtracker. Whereas .oO(kernel) there is some projects\n    where the subcomponents are dealt with from very different teams,\n    very different way to release things, and they are interested with\n    their bugs, and their bugs only. They would prefer a very fast\n    interface to deal with their 1k bugs, and not worry about the 100k\n    the rest of the project has.\n    Branching bugs also makes sense you know ?\n\n> Now, to rule the world, BTs gain a lot more from being able to\n> integrate with different SCMs,\n\n  You are the one saying it. I beg to differ.\n\n> automated test systems (like tinderbox), MTAs (debbugs), wikis (traq),\n> stats tracking for PHBs (bugzilla), etc. So loose coupling wins here,\n> and git's SHA1s are great for that.\n\n  IMHO a BTS is a _low_ level tool. that's the road git took, I\nsometimes describe the plumbing git commands as the \"Assembler\" of the\nSCM world to friends when I talk to them about git. That's really the\nbest way to implement a thing: have a small small set of rock solid,\nwell designed tools, and build the others as porcelains with them.\n\n  Testing is a high level tool. I don't need to support them, I need to\nhave exactly the low level querying rocket-fast query interfaces so that\nintegration scripts are at most 100 lines long.\n\n> And at git's end we can get the smooth integration using/abusing that\n> loose coupling strategy. So if git-log/gitk/qgit grow some hooks that\n> can be used to perform a lookup... I can think of a perl script that\n> gets events for each SHA1 that git-rev-list produces and returns one\n> bug number, url and title (or more than one) that then git-log / gitk\n> / qgit / annotate can use to further \"decorate\" the commit info in a\n> similar style to what gitk is doing now with head names in each\n> commit.\n>\n> Would that fit your vision of a nicely integrated tracker?\n\n  Honestly ? No, because that would be horribly slow (but I'd love to be\nproven wrong).\n\n\nCheers,\n-- \n·O·  Pierre Habouzit\n··O                                                madcoder@debian.org\nOOO                                                http://www.madism.org\n"},{"id":"44607","messageId":"20070610140204.GA6730@artemis.madism.org","threadId":"8409","inReplyTo":"46a038f90706092359i43a6e834rc096e53a28fbee51@mail.gmail.com","subject":"Re: [RFC] git integrated bugtracking","fromName":"Pierre Habouzit","fromEmail":"madcoder@debian.org","sentAt":"2007-06-10T14:02:05Z","receivedAt":"2007-06-10T14:02:05Z","isPatch":false,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":"On Sun, Jun 10, 2007 at 06:59:13PM +1200, Martin Langhoff wrote:\n> On 6/10/07, Pierre Habouzit <madcoder@debian.org> wrote:\n> >  FWIW I've begun to work on this (for real). I've called the tool\n> >\"grit\". You can follow the developpement on:\n> >\n> >  * gitweb: http://git.madism.org/?p=grit.git;a=summary\n> >  * git:    git://git.madism.org/grit.git/\n>\n> Call me a fool, but writing a <new> bugtracker looks like a\n> boil-the-oceans scheme.\n\n  Sure, what if I like it anyway ?\n\n> Adding git & gitweb support to traq, bugzilla, mantis, gforge, etc is\n> what is going to make the difference. Most of those have already the\n> ability to \"link\" to one or more commits -- after the commits are done\n> and in GIT.\n\n  Sure, you can do that and still inherit from the many downsides of\nthose tools: central, needs another separate tool to work with, and a\ntool that nowadays tends to eat 500Mb of your memory if you take the\nmost hype implementation of it (Yes I'm describing a web browser), that\nis slow like hell (because yes, there is many clients at the same time\non the central server, that is overloaded like hell), and so on.\n\n  You can like central web UIs, your choice. And I suppose if grit works\nwell, there will be one at some point.\n\n> So you can tell your bugtracker\n> - which commit fixed it -- usually auto-linked if you include the\n> bugnumber in the commit message\n> - which commit added the test -- auto linked as above\n> - which commit introduced the bug -- if such thing exists and someone\n> digs it up\n\n  yeah, that is what bugtrackers already do. Though, that's of no use\nfor release managers. What is useful is what people call \"milestones\" in\ntrac e.g., meaning a set of bugs that has been flagged as needing to be\nfixed. And what a release manager need is a tool to deal with this set\nof bugs as a whole.\n\n  That's the same argument that Linus has against per-file tracking.\nAlso atm when you e.g. backport a patch that fixes this or this bug,\nyou're no BTS helps you tagging the bug as fixed in that branch as well.\nNot to mention that BTS I know do not make any use of the commits DAG.\nAnd for a very good reason, there is no real DAG in many existing tools\n(svn, cvs, ...).\n\n> If the bugtracker can also auto-link things that look committish in\n> text entered by users (someone might write \"bisect sez that f345e is\n> to blame\"), with tooltips indicating in which heads those commits\n> resides (like gitk does), then it's just gorgeous.\n\n  that's not up to the BTS tool to do that, it's way to high level. It's\nup to the importing filters/hooks that will parse the associated ML, and\nthat would translate that to useful low level BTS commands.\n\n\n> And definitely, if you use git as an alibi to write a new bugtracker,\n> don't use the \"works only with git\" as a feature. It should work with\n> as many SCMs as possible.\n\n  No it should not, because it can't. I want the distributed and\nBug status spanning-DAGS be a central feature. So that means that this\ntool can only work on top of SCMs that support that. ttbomk git, hg,\n_maybe_ bzr fit the description. I only know the former, but I really\nplan to write the tool in a way that the underlying SCM does not matters\n_too_ much. Maybe I'll fail. Honestly, I don't really care (yet ?).\n\n\n> OTOH, that's just me, I'm lazy and like to work on already-successful\n> projects that are 99% there for my needs (and where I can add that\n> 1%).\n\n  You're a lucky guy. All bug trackers I've used suck a way or another,\nthat impedes my workflow a lot. Let's cite a couple:\n  * bugzilla: takes more from the -zilla than from the BTS side. It's\n    huge, monstruous, slow (have ever used glibc's bugzilla ? it has\n    maybe 5k bugs, it's slow like if it ran on an Atari ST), complex,\n    the mail gateway suck hard, it's completely unusable for me. Believe\n    me, I've packaged KDE for 2 years in Debian, now am in the glibc\n    team. Every single day I have to work on this horrible tool is a\n    PITA.\n\n  * flyspray: I've been upstream for a short time. Visually nice, good\n    to work with, UI is great. Integration totally suck, worthless.\n    Can't use mails either, needs a Web Browser -> useless. The same\n    holds for mantis, roundup and a lot of other friends.\n\n  * debbugs: oh yeah there is a mail interface. So slow that you have to\n    wait up to 15 minutes to see your command be taken into account. And\n    when you have to deal with dozens of bugs (Yes I've done that on a\n    regular basis) you _have_ sometimes to wait for the answer to come\n    back (because you need an ID that will be in there e.g.) to continue\n    your work. That is unacceptable, you pass most of your time waiting.\n    Moreover sometimes you made an error in your commands, so you also\n    need to parse the anwer ... one day later because \"immediateley when\n    you still remembered what this was about\" is not an option.\n    Unacceptable again. The plus: it uses mboxes, hence is worthwile in\n    a hacking environment, it fits the workflow well.\n\n  * trac: very very very nice tool. I mean it. We use it at work, where\n    I have to suffer svn (through git-svn though). It's really nice (did\n    I repeat myself ?). THough, it's on top of svn, and you can't use\n    the Bugs informations from your repository. You can't say: I'm\n    backporting that patch into that branch. Now what affects this\n    branch please ? Trac can't answer that (and ttbomk now BTS really\n    can anyway, except Debian's debbugs instance, and it's somehow\n    limited). That is a question a release manager takes 80% of his time\n    to ask. I hope grit can take back to the 0.01% of his time, which is\n    still too much.\n\n\nOn Sun, Jun 10, 2007 at 08:55:21PM +1200, Martin Langhoff wrote:\n> On 6/10/07, Jan Hudec <bulb@ucw.cz> wrote:\n> >I don't know about any *distributed* bug tracker, which is the point\n> >here.\n>\n> As an end user, I suspect I _don't_ want to have to report a bug in a\n> distributed bug tracker ;-)\n\n  I trol^Wdiscuss everyday on debian's channel with friends that tell\nthat svn is the best tool ever, and that they would never ever use a\ndistributed SCM because it's too hard to understand. Your call.\n\n> > We have several distributed version control tools, but no other\n> > distributed tools for the other tasks in configuration management.\n>\n> Bugtrackers are co-owned by developers, users and (where they exist)\n> project managers.\n\n  That's exactly why distributed rock. Because everyone could _really_\nown _his_ bugtracker. This solves the same range of ACLish issues git\nsolves with respect to the code.\n\n> > - Distributed version control is designed to decrease the workload of\n> >   the central maintainer(s) while keeping him in control. But with\n> >   centralized\n>\n> And to provide a single place for users to report a problem and track\n> its status.\n\n  Why wouldn't it exist a \"public reporting interface\"-branch ? that\nwould be the same purpose as the mainline ~linus/linux2.6.git tree. And\nyou can build/instanciate your beloved web UI on top of that, and people\nwould just have to pull from there. What a shock, it's easy !\n\n> > If it uses git as it's database, which it probably will,\n>\n> Well - hmmm. Git's database is great at tracking _content identity_.\n> But a bug's content identity (description+comments+status) changes all\n> the time. I don't think it's naturally a good match.\n\n  Oh, because the code never changes. Doh, how stupid I am :)\n  No, really, you name your bug after the sha hash of the first report,\nI think that's pretty obvious. That gives you a bug name. Then you ask\ngit for \"what's the current sha for this bug in the tip of the BTS\nbranch\", then you ask \"so now what this new sha is pointing to in the\ncode\". That's a small indirection that I suppose is bearable.\n\n> > Yes. But for many people current bug tracking tools do NOT work 99%.\n>\n> Hmmm. I agree in that \"does not work disconnected\" is a big issue with\n> web tools, but debbugs works disconnected, and is good. Git's\n> bugtracker (git@vger) works disconnected too ;-) And googlegears might\n> help the rest of us. Is there any other problem with current BTs?\n\n  It's not integrated with the workflow. And sorry, but git@vger (or\nworkse lkml@vger).. it does not work. Maybe for git it does because the\nflow is still human manageable, and that it seems junio has enough time\nfor it. But for the kernel ? please. You should read Bastian Blank\nfrustration about regressions and nobody tracking them. Know why ?\nbecause there is no tool that is well known and well integrated in the\nworkflow. There is a long rant against kernel.org's bugzilla, you should\nread it as well. It's not really instructive (at least there wasn't\nanything new for me in it, I was already bought to many arguments in\nthere). But you'll see the world isn't as rosa-lila you think it is.\n\n\nOn Sun, Jun 10, 2007 at 08:38:03PM +1200, Martin Langhoff wrote:\n> On 6/10/07, Junio C Hamano <gitster@pobox.com> wrote:\n> > After looking at the above existing alternatives, some brave soul\n> > might decide and say, \"Hey, I can write something better in 2 weeks\"\n> > ;-).\n\n  I'm sure I could come up with something really better in say a\nmonth... If I hadn't paid work to do too :)\n\n> And \"it's closely integrated with git\" can actually be a misfeature.\n> Cool if it's what gets you going, but not enough for world domination\n> ;-)\n\n  It's a misfeature for you because you read it as \"non portable\".\nThat's a fair point. And like said, it may be extended to SCM's with the\nsame set of features I need to build it. But let's be honnest, I don't\ncare about a BTS that uses the smallest common set of features of SCM's.\nReading this list, you should know it's almost a void set. No, I think a\ngood BTS should make an excellent use of high level features of the SCM.\nThe real problem is, there is maybe 2 or 3 SCMs that have this set of\nstrong and good features. Too bad for the other, I can't work with them,\nthey suck hard, and I don't see why I should support bad practices\nanyways.\n\n  (Yes I'm also a guy with strong opinions too, it's not really\nrestricted to Linus ;p)\n\n> I agree it's useful, but I don't think it has any benefit having it in\n> the SCM _at all_. Having them in the BT is a lot more flexible -- and\n> the fact that git has stable commit IDs makes it easier to integrate\n> in a BT; as the BT can spot that the commit fixing bug 123 is now\n> merged into head ZZ as well as head YYY.\n\n  If you do that you loose:\n  * fastness, and I don't want to work with debbugs anymore.\n\n  * distribution: Meaning that for _one_ project everybody needs to use\n    this central bugtracker. Whereas .oO(kernel) there is some projects\n    where the subcomponents are dealt with from very different teams,\n    very different way to release things, and they are interested with\n    their bugs, and their bugs only. They would prefer a very fast\n    interface to deal with their 1k bugs, and not worry about the 100k\n    the rest of the project has.\n    Branching bugs also makes sense you know ?\n\n> Now, to rule the world, BTs gain a lot more from being able to\n> integrate with different SCMs,\n\n  You are the one saying it. I beg to differ.\n\n> automated test systems (like tinderbox), MTAs (debbugs), wikis (traq),\n> stats tracking for PHBs (bugzilla), etc. So loose coupling wins here,\n> and git's SHA1s are great for that.\n\n  IMHO a BTS is a _low_ level tool. that's the road git took, I\nsometimes describe the plumbing git commands as the \"Assembler\" of the\nSCM world to friends when I talk to them about git. That's really the\nbest way to implement a thing: have a small small set of rock solid,\nwell designed tools, and build the others as porcelains with them.\n\n  Testing is a high level tool. I don't need to support them, I need to\nhave exactly the low level querying rocket-fast query interfaces so that\nintegration scripts are at most 100 lines long.\n\n> And at git's end we can get the smooth integration using/abusing that\n> loose coupling strategy. So if git-log/gitk/qgit grow some hooks that\n> can be used to perform a lookup... I can think of a perl script that\n> gets events for each SHA1 that git-rev-list produces and returns one\n> bug number, url and title (or more than one) that then git-log / gitk\n> / qgit / annotate can use to further \"decorate\" the commit info in a\n> similar style to what gitk is doing now with head names in each\n> commit.\n>\n> Would that fit your vision of a nicely integrated tracker?\n\n  Honestly ? No, because that would be horribly slow (but I'd love to be\nproved wrong).\n\nCheers,\n-- \n·O·  Pierre Habouzit\n··O                                                madcoder@debian.org\nOOO                                                http://www.madism.org\n"},{"id":"44650","messageId":"vpqwsybo44j.fsf@bauges.imag.fr","threadId":"8409","inReplyTo":"20070610083754.GC4084@efreet.light.src","subject":"Re: [RFC] git integrated bugtracking","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2007-06-10T22:07:24Z","receivedAt":"2007-06-10T22:07:24Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Jan Hudec <bulb@ucw.cz> writes:\n\n> A related thing is Bazaar's \"Bundle Buggy\". It tracks patch submission rather\n> than bugs, but it is roughly what I meant by the \"mailing list integration\"\n> above. It \"reads\" the mailing list, watching for anything labeled [PATCH] or\n> [BUNDLE]\n\nIndeed, the bundle buggy is inspired from the \"Bug goo\" developed\nearlier for GNU Arch. This one was watching mails labeled with [BUG]\non the mailing list.\n\nI found the idea really good. Indeed, as a user, when I find a bug in\na piece of software, I often hesitate between using the bugtracker (in\nwhich case my bug is often mostly ignored), or reporting it on the\nmailing list (in which case, a long discussion can follow, at the end\nof which everybody thinks that someone else will fix the bug, and no\none actually does). With the bug goo, the bugtracker becomes the\nmailing list, with all the advantage of it (discussions easy to\nfollow, threaded, ...), and a few additions, the biggest of which is\nstatus tracking, in particular, the ability to list all unsolved bugs.\n\nUnfortunately, as most of the GNU Arch stuff, it started with good\nideas, but was abandonned before it started being interesting :-\\.\n\n-- \nMatthieu\n"},{"id":"44660","messageId":"46a038f90706101614h48112deel70d848f4312c88d7@mail.gmail.com","threadId":"8409","inReplyTo":"20070610101616.GF2951@artemis","subject":"Re: [RFC] git integrated bugtracking","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2007-06-10T23:14:03Z","receivedAt":"2007-06-10T23:14:03Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 6/10/07, Pierre Habouzit <madcoder@debian.org> wrote:\n> On Sun, Jun 10, 2007 at 06:59:13PM +1200, Martin Langhoff wrote:\n> >\n> > Call me a fool, but writing a <new> bugtracker looks like a\n> > boil-the-oceans scheme.\n>\n>   Sure, what if I like it anyway ?\n\nBe my guest. It might turn out to be a beautiful project, but has low\nchances of helping GIT-BTS integration in general.\n\n> > Adding git & gitweb support to traq, bugzilla, mantis, gforge, etc is\n> > what is going to make the difference. Most of those have already the\n> > ability to \"link\" to one or more commits -- after the commits are done\n> > and in GIT.\n>\n>   Sure, you can do that and still inherit from the many downsides of\n> those tools: central, needs another separate tool to work with, and a\n> tool that nowadays tends to eat 500Mb of your memory if you take the\n> most hype implementation of it (Yes I'm describing a web browser), that\n> is slow like hell (because yes, there is many clients at the same time\n> on the central server, that is overloaded like hell), and so on.\n\nMost usable BTSs work on lighter webbrowsers, and can be tuned to work\nreasonably. That's not a dead-end per se.\n\n>   You can like central web UIs, your choice. And I suppose if grit works\n> well, there will be one at some point.\n\nBugtrackers are communication tools between developers and users. In\nmany spaces, they are _teaching tools_, teaching the users about info\ndevelopers need. That's why BTSs have explicit fields asking for\nimportant variables like OS, Arch, and version you are reporting a bug\nagainst. That's also why the BTS gains a lot from being web-based:\nextreme portability, reachability, zero-install for users.\n\n> > So you can tell your bugtracker\n> > - which commit fixed it -- usually auto-linked if you include the\n> > bugnumber in the commit message\n> > - which commit added the test -- auto linked as above\n> > - which commit introduced the bug -- if such thing exists and someone\n> > digs it up\n>\n>   yeah, that is what bugtrackers already do. Though, that's of no use\n> for release managers. What is useful is what people call \"milestones\" in\n> trac e.g., meaning a set of bugs that has been flagged as needing to be\n> fixed. And what a release manager need is a tool to deal with this set\n> of bugs as a whole.\n\nHmmm. Most BTSs have milestones, and the integration of the above with\nmilestones is useful for release managers. How about the _rest_ of the\nBTS-using populace?\n\n>   That's the same argument that Linus has against per-file tracking.\n> Also atm when you e.g. backport a patch that fixes this or this bug,\n> you're no BTS helps you tagging the bug as fixed in that branch as well.\n> Not to mention that BTS I know do not make any use of the commits DAG.\n> And for a very good reason, there is no real DAG in many existing tools\n> (svn, cvs, ...).\n\nMaking the BTS DAG-aware is overkill. The BTS can ask for every update\non every branch \"what commits does it bring into branch X?\" and that's\nall you need. If you backport a patch and mention the original patch\nSHA1 the BTS can do its job.\n\nAnd all of that can be done SCM-agnostic - except for the regex to\nspot a commitid.\n\n> > And definitely, if you use git as an alibi to write a new bugtracker,\n> > don't use the \"works only with git\" as a feature. It should work with\n> > as many SCMs as possible.\n>\n>   No it should not, because it can't. I want the distributed and\n> Bug status spanning-DAGS be a central feature.\n\nBut you lose portability. And gain... what that you can't do portably?\n>   You're a lucky guy. All bug trackers I've used suck a way or another,\n> that impedes my workflow a lot. Let's cite a couple:\n\nOk - but BTSs are a compromise, something that must work for users,\nand developers.\n\n> > Bugtrackers are co-owned by developers, users and (where they exist)\n> > project managers.\n>\n>   That's exactly why distributed rock. Because everyone could _really_\n> own _his_ bugtracker. This solves the same range of ACLish issues git\n> solves with respect to the code.\n\nDon't think I've seen politics over who owns the bugtracker ;-) but I\n_have_ seen politics over specific bugs (developers close unfixed\nbugs, flamefests ensue). I guess with a DBTS everyone can have their\nown status for the bug... but does that help the user? Or the\ndeveloper?\n\n> > Well - hmmm. Git's database is great at tracking _content identity_.\n> > But a bug's content identity (description+comments+status) changes all\n> > the time. I don't think it's naturally a good match.\n>\n>   Oh, because the code never changes. Doh, how stupid I am :)\n>   No, really, you name your bug after the sha hash of the first report,\n> I think that's pretty obvious. That gives you a bug name. Then you ask\n> git for \"what's the current sha for this bug in the tip of the BTS\n> branch\", then you ask \"so now what this new sha is pointing to in the\n> code\". That's a small indirection that I suppose is bearable.\n\nOf course, you _can_ map the DBTS storage on git's storage. But git's\nstorage has been designed to match the task. While I'm sure there are\nsome good tricks to reuse, I don't think that it's a good fit.\n\n> > And at git's end we can get the smooth integration using/abusing that\n> > loose coupling strategy. So if git-log/gitk/qgit grow some hooks that\n> > can be used to perform a lookup... I can think of a perl script that\n> > gets events for each SHA1 that git-rev-list produces and returns one\n> > bug number, url and title (or more than one) that then git-log / gitk\n> > / qgit / annotate can use to further \"decorate\" the commit info in a\n> > similar style to what gitk is doing now with head names in each\n> > commit.\n> >\n> > Would that fit your vision of a nicely integrated tracker?\n>\n>   Honestly ? No, because that would be horribly slow (but I'd love to be\n> proven wrong).\n\nWhat part would be slow?\n\ncheers\n\n\n\nmartin\n"},{"id":"44706","messageId":"20070611084533.GA24327@artemis.intersec.eu","threadId":"8409","inReplyTo":"46a038f90706101614h48112deel70d848f4312c88d7@mail.gmail.com","subject":"Re: [RFC] git integrated bugtracking","fromName":"Pierre Habouzit","fromEmail":"madcoder@debian.org","sentAt":"2007-06-11T08:45:33Z","receivedAt":"2007-06-11T08:45:33Z","isPatch":false,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":"On Mon, Jun 11, 2007 at 11:14:03AM +1200, Martin Langhoff wrote:\n> On 6/10/07, Pierre Habouzit <madcoder@debian.org> wrote:\n> > On Sun, Jun 10, 2007 at 06:59:13PM +1200, Martin Langhoff wrote:\n> >> Adding git & gitweb support to traq, bugzilla, mantis, gforge, etc is\n> >> what is going to make the difference. Most of those have already the\n> >> ability to \"link\" to one or more commits -- after the commits are done\n> >> and in GIT.\n> >\n> >  Sure, you can do that and still inherit from the many downsides of\n> >those tools: central, needs another separate tool to work with, and a\n> >tool that nowadays tends to eat 500Mb of your memory if you take the\n> >most hype implementation of it (Yes I'm describing a web browser), that\n> >is slow like hell (because yes, there is many clients at the same time\n> >on the central server, that is overloaded like hell), and so on.\n>\n> Most usable BTSs work on lighter webbrowsers, and can be tuned to work\n> reasonably. That's not a dead-end per se.\n\n  okay, my point is also that using yet another tool that is neither\nintegrated in my shell nor in my editor sucks. I use the shell to use\n$SCM, and to perform tests of my work, so it's in my workflow. I use the\neditor (well do I need to tell why ? :P), I just don't want to use a\nbrowser where the two previous should be enough.\n\n> >  You can like central web UIs, your choice. And I suppose if grit works\n> >well, there will be one at some point.\n> \n> Bugtrackers are communication tools between developers and users. In\n> many spaces, they are _teaching tools_, teaching the users about info\n> developers need. That's why BTSs have explicit fields asking for\n> important variables like OS, Arch, and version you are reporting a bug\n> against. That's also why the BTS gains a lot from being web-based:\n> extreme portability, reachability, zero-install for users.\n\n  Because it's git-based does not implies there won't be a web UI. And\nit's not because there is a lot of options to the underlying process\nthat you need to show them all to the user.\n\n  My experience is also that people never fill informations about OS,\nArch, version properly, because it's tiredsome. debbugs (through\nreportbug) approach is excellent: assuming that the user reports the\nerror from the machine where he experienced it and taking all the\ninformation automatically. _here_ is how it should work for the user,\ne.g.: “please download and run that script, and paste the results in your\nbug report pretty please ?”\n\n> >  yeah, that is what bugtrackers already do. Though, that's of no use\n> >for release managers. What is useful is what people call \"milestones\" in\n> >trac e.g., meaning a set of bugs that has been flagged as needing to be\n> >fixed. And what a release manager need is a tool to deal with this set\n> >of bugs as a whole.\n> \n> Hmmm. Most BTSs have milestones, and the integration of the above with\n> milestones is useful for release managers.\n\n  How many of those bts'es help the RMs to know if their\nsoon-to-be-stable branch fits the milestone ? milestones in any BTS I\nknow are global \"yes the fix exists, in this revision (and this\ninformation is not always here)\". Sorry but it's worthless.\n\n> How about the _rest_ of the BTS-using populace?\n\n  Okay, who else uses a BTS ? developpers, as I'm a developper, I'll\nwrite a tool that pleases me. Let's say developpers are taken care of.\n\n  Users ? For a user, what should be made easy is reporting, and\ninteracting with whoever is dealing with the bug on the other end.\nAdvanced users will want to be able to track discussion about some bugs\nthey are interested into (meaning that it must be a way to crawl the\nbugs database).\n\n  So let's take the three points:\n  * reporting: the tools to make reporting fast, efficient, _and_\n    useful to the developpers - many many many bug reports suck, hard -\n    are very often project dependant: a project in python e.g. won't\n    care about the architecture usually (hence forcing it is stupid) but\n    will probably mind the OS, python version, distribution, ... Another\n    project in C will mind the architecture, but is knowingly working\n    only on Linux so won't mind the OS, but would maybe mind the kernel\n    version. etc...\n\n    => What can I do ? provide a way to deal with some kind of\n       property/values that can be customizeable at the BTS side and\n       show some examples of reporting scripts. ttbomk only debbugs and\n       reportbug knows how to do that. It does not prevents bad bug\n       reports at all, but it makes many that would have been bad almost\n       good, at least usable.\n\n  * simplicity to follow up: there isn't 12987123 solutions here. mail,\n    mail, mail, mail. A BTS should be able to track mail discussions one\n    way or another. For pure-web BTS, there is still mail alerts to say\n    \"hey $someone has said $sth on your bug $bug\". So the user already\n    is in his MUA when he receives that, well, \"reply\"-button is the\n    shortest way to answer, make it possible.\n\n  * crawling the database: that one should not be done by the BTS. Every\n    BTS on the planet doing that is wrong. There is plenty of good\n    search engines (xapian, clucene, ...) just adapt one. And the most\n    simple your storage backend is, the simplest it will be.\n\n  What I'm saying is that maybe we don't call BTS the same object. To me\na BTS is a \"thing\" able to deal with large amounts of bugs in an\nefficient way, and is able to deal with some basic things like bug\nstatuses, and some kind of queries to the database (not the full text\nsearch ones). Then you have the Upper Layer Tools: guis, tracking\nscripts, every bling you need. Note that Git is exactly designed this\nway: low level tools, and then tools like git-mergetool, gitk, ... that\ndon't use _any_ git internal, but rather only use the underlying\ncommands. I want to build the core functions to deal with a BTS, so that\neverybody is able to turn this into the BTS workflow he needs.\n\n> >  That's the same argument that Linus has against per-file tracking.\n> >Also atm when you e.g. backport a patch that fixes this or this bug,\n> >you're no BTS helps you tagging the bug as fixed in that branch as well.\n> >Not to mention that BTS I know do not make any use of the commits DAG.\n> >And for a very good reason, there is no real DAG in many existing tools\n> >(svn, cvs, ...).\n> \n> Making the BTS DAG-aware is overkill.\n\n  Why ?\n\n> The BTS can ask for every update on every branch \"what commits does it\n> bring into branch X?\" and that's all you need. If you backport a patch\n> and mention the original patch SHA1 the BTS can do its job.\n\n  or the BTS can do it for you and you would not need to feed him with\nthe sha directly.\n\n> And all of that can be done SCM-agnostic - except for the regex to\n> spot a commitid.\n\n  Sure, there is projects doing that out there, I believe they are\nwrong. Portability is important. I mean, when you write a tool, that has\na purpose, yes you must try to make it available everywhere. That's why\nthere are people trying hard to make git build and work on windows.\n\n  But when you write a tool to help _you_ work, there is now need to\nmake it work for every workflow in the planet, because that would mean\nalign yourself to the lowest common denominator of the workflows you can\nwork with. That's not an acceptable trade-off. Why would I have to\nsupport cvs or svn ? I don't use them. I just don't care about them.\nWherever place I'll work in, I'll use git. Sorry but full genericity\n(because it's what we are talking about, not portability) is an\nimpediment, not an enabler.\n\n> >  You're a lucky guy. All bug trackers I've used suck a way or another,\n> >that impedes my workflow a lot. Let's cite a couple:\n>\n> Ok - but BTSs are a compromise, something that must work for users,\n> and developers.\n\n  I don't think it needs to be a compromise.\n\n> >> Bugtrackers are co-owned by developers, users and (where they exist)\n> >> project managers.\n> >\n> >  That's exactly why distributed rock. Because everyone could _really_\n> >own _his_ bugtracker. This solves the same range of ACLish issues git\n> >solves with respect to the code.\n> \n> Don't think I've seen politics over who owns the bugtracker ;-) but I\n> _have_ seen politics over specific bugs (developers close unfixed\n> bugs, flamefests ensue). I guess with a DBTS everyone can have their\n> own status for the bug... but does that help the user? Or the\n> developer?\n\n  That one is easy. Indeed, the big politics in bugtrackers are ...\nseverity-ping-pong, or close-wars. Good example of that is btw:\nhttp://sourceware.org/bugzilla/show_bug.cgi?id=4509.\n\n  Okay, what would we gain in a DBTS: developer would still be (sorry)\na perfect asshole with the user. That is a thing we cannot fix. Though,\nthe release manager will probably disagree with him. So this bug that\n_he_ considers non existant will be closed in his repository, but still\nremain open in the main one. Meaning that if another developer steps up,\nhe'll see this issue is not fixed. Else nobody will have any chance to\nstep up, ever.\n\n  The reverse works equally well: if RM decides bugs have to be closed,\ndeveloper is able to reopen the bugs (or not merge) in his repository,\nso that he can have a chance to fix them.\n\n  Yes there is politics in BTSes, and yes it can help.\n\n> > > And at git's end we can get the smooth integration using/abusing\n> > > that loose coupling strategy. So if git-log/gitk/qgit grow some\n> > > hooks that can be used to perform a lookup... I can think of a\n> > > perl script that gets events for each SHA1 that git-rev-list\n> > > produces and returns one bug number, url and title (or more than\n> > > one) that then git-log / gitk / qgit / annotate can use to further\n> > > \"decorate\" the commit info in a similar style to what gitk is\n> > > doing now with head names in each commit.\n> > >\n> > > Would that fit your vision of a nicely integrated tracker?\n> >\n> >  Honestly ? No, because that would be horribly slow (but I'd love to be\n> >proven wrong).\n>\n> What part would be slow?\n\n  The perl scripts. It would perceptibly slow down commits. And I don't\nwant that now that I finally have a fast SCM. I just don't want to turn\ngit into bzr.\n\n-- \n·O·  Pierre Habouzit\n··O                                                madcoder@debian.org\nOOO                                                http://www.madism.org\n"},{"id":"44713","messageId":"46a038f90706110300r20dd992excfcb6fbd9d2b8d6c@mail.gmail.com","threadId":"8409","inReplyTo":"20070611084533.GA24327@artemis.intersec.eu","subject":"Re: [RFC] git integrated bugtracking","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2007-06-11T10:00:48Z","receivedAt":"2007-06-11T10:00:48Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 6/11/07, Pierre Habouzit <madcoder@debian.org> wrote:\n>   That one is easy. Indeed, the big politics in bugtrackers are ...\n> severity-ping-pong, or close-wars. Good example of that is btw:\n> http://sourceware.org/bugzilla/show_bug.cgi?id=4509.\n>\n>   Okay, what would we gain in a DBTS: developer would still be (sorry)\n> a perfect asshole with the user. That is a thing we cannot fix. Though,\n> the release manager will probably disagree with him. So this bug that\n> _he_ considers non existant will be closed in his repository, but still\n> remain open in the main one. Meaning that if another developer steps up,\n> he'll see this issue is not fixed. Else nobody will have any chance to\n> step up, ever.\n\nI've seen all those bugtracker-wars. But they never block a developer\nor fellow user from saying --hey, here's a patch. And with a DSCM,\nthat clears things up quite quickly.\n\nI don't understand how  \"Else nobody will have any chance to step up, ever.\"\n\n> > >  Honestly ? No, because that would be horribly slow (but I'd love to be\n> > >proven wrong).\n> >\n> > What part would be slow?\n>\n>   The perl scripts. It would perceptibly slow down commits. And I don't\n> want that now that I finally have a fast SCM. I just don't want to turn\n> git into bzr.\n\nThe model I was thinking of was of _not_ slowing down your commits ;-) but\n\n * Stick to a mostly centralised BTS that tracks a limited set of repos\n * When you push to the public repo, the BTS updates its bug status\n * on git-pull, update a (fast!) local cache of BTS data\n * on gitk use a similar technique to the \"follows\" line shown for\neach commit to display bug info \"inline\"\n\ncheers,\n\n\nmartin\n"},{"id":"44741","messageId":"1181587892.3380.37.camel@ld0161-tx32","threadId":"8409","inReplyTo":"20070610085044.GD4084@efreet.light.src","subject":"Re: [RFC] git integrated bugtracking","fromName":"Jon Loeliger","fromEmail":"jdl@freescale.com","sentAt":"2007-06-11T18:51:32Z","receivedAt":"2007-06-11T18:51:32Z","isPatch":false,"sender":{"key":"jdl@jdl.com","avatar":"https://gravatar.com/avatar/75ce9a10b151acd2c28ec4ab2136dba7b2ff1634530bd04b155981a749d08a64?d=mp&s=160"},"body":"On Sun, 2007-06-10 at 03:50, Jan Hudec wrote:\n\n> \n> It would be really useful to have a tool, that could link a bug report to\n> a test case demonstrating it and reporting whenever output of that test case\n> changes. This would make it much easier for developer to see which bugs he\n> might have fixed when doing a refactoring.\n\nI think the inverse is interesting too.  That is, applying\nkeywords to tests and then making the test database\nkeywords searchable.\n\nI used to work for a company that had a huge collection\nof test cases for its product.  It would take days to run\na validation run for some of the simplest of changes that\nwere introduced during development.\n\nOften what I wanted, and what was needed, was a simple\nsanity check that verified that the proposed change was\nnot brain-dead from the start.\n\nOver time, I found that certain tests proved to be good\nat detecting failures in particular portions of the code.\nOften, that test was not necessarily directly related to\nthe concept it was _supposed_ to be designed to test, but\nincidentally was good at some _other_ concept too.\n\nThe developer who made the change, and ran the tests,\nthen was able to state \"Test t42 from suite Frotz is good\nat detecting changes to the <SomeModule>.\"\n\nThe trick is to now associate with that test the keyword\n\"SomeModule\" so that in the future, another developer\ncould ask:  \"Say, I just modified <SomeModule>, are there\nany tests that are good at proving my changes sound?\"\nA test driver could then focus some test cycles quickly.\n\nNow, for git, it's not likely a problem to just run\nthrough all of its tests.  At ${PriorCompany} it was\nessential to pare down the test suites to a manageable\nsize, yet still have assurance that your coverage was\nreasonably good.\n\njdl\n"},{"id":"44810","messageId":"8b65902a0706120154n410c1bdbp744198aef070e3f5@mail.gmail.com","threadId":"8409","inReplyTo":"1181587892.3380.37.camel@ld0161-tx32","subject":"Re: [RFC] git integrated bugtracking","fromName":"Guilhem Bonnefille","fromEmail":"guilhem.bonnefille@gmail.com","sentAt":"2007-06-12T08:54:36Z","receivedAt":"2007-06-12T08:54:36Z","isPatch":false,"sender":{"key":"guilhem.bonnefille@gmail.com","avatar":"https://gravatar.com/avatar/375364bfee1f61197c540e37465abe3619fc24eb3a36b0edcea7f15b124036b0?d=mp&s=160"},"body":"Hi,\n\nThis subject is quite interesting. I read that one of the main\nexpected goal of integrating SCM and BT is to help release manager in\nits task.\n\nIn my point of view, we have to keep in mind that it's not because a\ncommit solved a problem, that all the following commits will always\nsolve the problem. Development ALWAYS suffers regression. The really\nway to avoid this is to have an organisation of code that allows\nautomatic tests. So it needs something greater than the SCM: you have\nto be organized for this.\n\nOne interesting project to have a look for is aegis (\nhttp://aegis.sourceforge.net/ ).\nIt proposes a sort of SCM, that integrates process to ensure quality\nof code. One of them is that the /SCM/ will control the non regression\nbefore commiting.\n\nI hope these informations will help defining how we can design a\nsystem that integrates SCM and BT in a distributed manner.\n-- \nGuilhem BONNEFILLE\n-=- #UIN: 15146515 JID: guyou@im.apinc.org MSN: guilhem_bonnefille@hotmail.com\n-=- mailto:guilhem.bonnefille@gmail.com\n-=- http://nathguil.free.fr/\n"}]}