{"thread":{"id":"37882","subject":"[Opinions] Integrated tickets","startedAt":"2014-11-05T12:44:29Z","lastAt":"2014-11-11T18:24:23Z","messageCount":7,"participants":["Fredrik Gustafsson","Jeff King","Junio C Hamano","Holger Hellmuth"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"251406","messageId":"20141105124429.GF15384@paksenarrion.iveqy.com","threadId":"37882","inReplyTo":null,"subject":"[Opinions] Integrated tickets","fromName":"Fredrik Gustafsson","fromEmail":"iveqy@iveqy.com","sentAt":"2014-11-05T12:44:29Z","receivedAt":"2014-11-05T12:44:29Z","isPatch":false,"sender":{"key":"iveqy@iveqy.com","avatar":"https://avatars.githubusercontent.com/u/761743?v=4"},"body":"Hi,\nmany developers rely on ticket systems (githubs issues, trac, bugzilla,\netc.). To me a ticket often has a relation to one or more commits.\n\nHence, even if git is functional in an offline enviroment, I can't work\nfully since none of the ticket systems above is distributed.\n\nThis can be solved with a distributed ticket system. Fossil SCM is one\nexample of an integrated ticket system into a scm (although please don't\nthink about this is something that must be web-based).\n\nSo my question is:\n\nwhat's your opinions on building an integrated ticket system on top of git?\n\nand (maybe mostly for Junio)\n\nWould such system possible be included in git.git?\n\nTL;DR;\nIs an integrated ticket system something for git?\n-- \nMed vänlig hälsning\nFredrik Gustafsson\n\ntel: 0733-608274\ne-post: iveqy@iveqy.com\n"},{"id":"251427","messageId":"20141106055348.GC22835@peff.net","threadId":"37882","inReplyTo":"20141105124429.GF15384@paksenarrion.iveqy.com","subject":"Re: [Opinions] Integrated tickets","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-11-06T05:53:48Z","receivedAt":"2014-11-06T05:53:48Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Nov 05, 2014 at 01:44:29PM +0100, Fredrik Gustafsson wrote:\n\n> So my question is:\n> \n> what's your opinions on building an integrated ticket system on top of git?\n\nI think it's a nice concept, but there have been several\nimplementations, and AFAIK none of them is incredibly popular. I do not\nknow offhand if the problem is the concept or the implementations (I\nlooked at them long ago but don't remember enough to provide any sort of\nreasonable critique).\n\nI started to assemble a list of pointers, but I realized that 4 out of 5\nof the projects that I had looked at a few years ago no longer exist. ;)\n\nHere's an article from last year with a nice overview of the (non-)state\nand links to other sources:\n\n https://www.stationary-traveller.eu/distributed-bug-trackers.html\n\n> and (maybe mostly for Junio)\n> \n> Would such system possible be included in git.git?\n\nI am not Junio, but I would have to say: probably not. This seems like\nsomething that can very easily sit on _top_ of git and use the git\nplumbing. In the long-term git may want to grow features to make\nintegration more seamless, but we'd probably want to add them in a more\nfunctionality-agnostic way (e.g., don't grow an option to attach bug\ninformation to a commit; grow an option to attach arbitrary information\nto a commit. We already have this part in the form of \"git notes\", but\nthere are likely other opportunities for integration).\n\n-Peff\n"},{"id":"251439","messageId":"xmqqvbmsgocj.fsf@gitster.dls.corp.google.com","threadId":"37882","inReplyTo":"20141105124429.GF15384@paksenarrion.iveqy.com","subject":"Re: [Opinions] Integrated tickets","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-11-06T18:45:16Z","receivedAt":"2014-11-06T18:45:16Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Fredrik Gustafsson writes:\n\n> So my question is:\n>\n> what's your opinions on building an integrated ticket system on top of git?\n>\n> and (maybe mostly for Junio)\n>\n> Would such system possible be included in git.git?\n>\n> TL;DR;\n> Is an integrated ticket system something for git?\n\nIntegrated? Not really, unless we already have a clear winner in\nthe marketplace that we can just ship in contrib/ or something, and\neven then, the Git ecosystem is now rich enough and the userbase\nstrong enough that having something in contrib/ adds much less value\nthan additional burden of having to keep up with the upstream, and\nuser confusion coming from possible version skew from the upstream.\nIt used to make a lot of sense to ship Git with things like gitweb\nand gitk when we were trying to gain momentum, but it is no longer\n2005 ;-). Even kernel.org does not run gitweb anymore.\n\nThis is a tangent, but I personally do not think \"ticket\" meshes\nvery well with \"commit\". If you already know which commit was\nproblematic, why are you annotating it with a ticket before\nreverting it first?\n"},{"id":"251715","messageId":"54620522.4060600@ira.uka.de","threadId":"37882","inReplyTo":"xmqqvbmsgocj.fsf@gitster.dls.corp.google.com","subject":"Re: [Opinions] Integrated tickets","fromName":"Holger Hellmuth","fromEmail":"hellmuth@ira.uka.de","sentAt":"2014-11-11T12:46:26Z","receivedAt":"2014-11-11T12:46:26Z","isPatch":false,"sender":{"key":"hellmuth@ira.uka.de","avatar":null},"body":"Am 06.11.2014 um 19:45 schrieb Junio C Hamano:\n> This is a tangent, but I personally do not think \"ticket\" meshes\n> very well with \"commit\". If you already know which commit was\n> problematic, why are you annotating it with a ticket before\n> reverting it first?\n\nI would expect a ticket to be annotating the commit or version tag where \nthe bug was found, which usually isn't the commit where the bug was \nintroduced.\n"},{"id":"251720","messageId":"xmqqioil7j20.fsf@gitster.dls.corp.google.com","threadId":"37882","inReplyTo":"54620522.4060600@ira.uka.de","subject":"Re: [Opinions] Integrated tickets","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-11-11T17:17:59Z","receivedAt":"2014-11-11T17:17:59Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Holger Hellmuth writes:\n\n> Am 06.11.2014 um 19:45 schrieb Junio C Hamano:\n>> This is a tangent, but I personally do not think \"ticket\" meshes\n>> very well with \"commit\". If you already know which commit was\n>> problematic, why are you annotating it with a ticket before\n>> reverting it first?\n>\n> I would expect a ticket to be annotating the commit or version tag\n> where the bug was found, which usually isn't the commit where the bug\n> was introduced.\n\nYou could arrange your \"tickets\" in such a way, but in general, the\nway you organize your data should match how the data is expected to\ncommonly be accessed.\n\nIf somebody finds a bug when the version he happened to be using was\nv1.8.5-9-g144d846, do you mean to attach that ticket to that exact\ncommit? Or do you use v1.8.5^0 (i.e. the closest tagged version)\nafter making sure that it is not a commit between these two that\nintroduced it as a new bug?\n\nEither way, I do not see how such an arrangement is the most\nconvenient way to organize the tickets and ask questions such as\n\"what are the known, untriaged, or unresolved issues in v1.8.5?\",\n\"what are the issues that didn't exist in v1.7.0 but appear in\nv1.8.5?\", \"what are the outstanding issues around refs handling that\nare the highest priority?\", etc. With your arrangement of data, any\nof the common questions I think of asking would require a linear\nscan of a commit range, followed by an enumeration and parsing of\nall the notes attached to the commits to answer.\n\nSo I would have to say that your expectation makes even less sense\nthan annotating an exact buggy commit with a note saying what is\nbroken by it.\n"},{"id":"251723","messageId":"54625253.4070903@ira.uka.de","threadId":"37882","inReplyTo":"xmqqioil7j20.fsf@gitster.dls.corp.google.com","subject":"Re: [Opinions] Integrated tickets","fromName":"Holger Hellmuth","fromEmail":"hellmuth@ira.uka.de","sentAt":"2014-11-11T18:15:47Z","receivedAt":"2014-11-11T18:15:47Z","isPatch":false,"sender":{"key":"hellmuth@ira.uka.de","avatar":null},"body":"Am 11.11.2014 um 18:17 schrieb Junio C Hamano:\n> Holger Hellmuth writes:\n>\n>> Am 06.11.2014 um 19:45 schrieb Junio C Hamano:\n>>> This is a tangent, but I personally do not think \"ticket\" meshes\n>>> very well with \"commit\". If you already know which commit was\n>>> problematic, why are you annotating it with a ticket before\n>>> reverting it first?\n>>\n>> I would expect a ticket to be annotating the commit or version tag\n>> where the bug was found, which usually isn't the commit where the bug\n>> was introduced.\n\n[...]\n\n> Either way, I do not see how such an arrangement is the most\n> convenient way to organize the tickets and ask questions such as\n> \"what are the known, untriaged, or unresolved issues in v1.8.5?\",\n> \"what are the issues that didn't exist in v1.7.0 but appear in\n> v1.8.5?\", \"what are the outstanding issues around refs handling that\n> are the highest priority?\", etc. With your arrangement of data, any\n> of the common questions I think of asking would require a linear\n> scan of a commit range, followed by an enumeration and parsing of\n> all the notes attached to the commits to answer.\n>\n> So I would have to say that your expectation makes even less sense\n> than annotating an exact buggy commit with a note saying what is\n> broken by it.\n\nNot less sense, because with tickets attached to the exact buggy commit \none would have the same problems answering the questions above. I don't \ndispute that tickets and commits don't mesh, it was the reason that you \ngave the first time that didn't sound right. Sorry if I have wasted your \ntime, but looking at it from the management side removed any lingering \ndoubts for me that there might be a benefit to an integration, even if \nsome sort of indexing or database was used.\n"},{"id":"251724","messageId":"xmqqzjbx61ew.fsf@gitster.dls.corp.google.com","threadId":"37882","inReplyTo":"xmqqioil7j20.fsf@gitster.dls.corp.google.com","subject":"Re: [Opinions] Integrated tickets","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-11-11T18:24:23Z","receivedAt":"2014-11-11T18:24:23Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Either way, I do not see how such an arrangement is the most\n> convenient way to organize the tickets and ask questions such as\n> \"what are the known, untriaged, or unresolved issues in v1.8.5?\",\n> \"what are the issues that didn't exist in v1.7.0 but appear in\n> v1.8.5?\", \"what are the outstanding issues around refs handling that\n> are the highest priority?\", etc. With your arrangement of data, any\n> of the common questions I think of asking would require a linear\n> scan of a commit range, followed by an enumeration and parsing of\n> all the notes attached to the commits to answer.\n>\n> So I would have to say that your expectation makes even less sense\n> than annotating an exact buggy commit with a note saying what is\n> broken by it.\n\nNot that annotating the commit as \"this commit has this bug\" makes\nmuch sense, though, of course ;-) But at least it would let us\nanswer \"Does this commit introduce a bug?\" question, and if the\nannotated information also records \"... and that other commit is a\nfix that can be cherry-picked (or merged)\", that would be even\nbetter. That would allow us, when merging down the commit thusly\nannotated, to stop and consider either not merging (because it is\nknown to introduce a bug) or merging with fixes also merged (because\nthe solution is already known and recorded).\n"}]}