From: Holger Hellmuth Date: Tue, 11 Nov 2014 18:15:47 GMT Subject: Re: [Opinions] Integrated tickets Message-ID: <54625253.4070903@ira.uka.de> In-Reply-To: Am 11.11.2014 um 18:17 schrieb Junio C Hamano: > Holger Hellmuth writes: > >> Am 06.11.2014 um 19:45 schrieb Junio C Hamano: >>> This is a tangent, but I personally do not think "ticket" meshes >>> very well with "commit". If you already know which commit was >>> problematic, why are you annotating it with a ticket before >>> reverting it first? >> >> I would expect a ticket to be annotating the commit or version tag >> where the bug was found, which usually isn't the commit where the bug >> was introduced. [...] > Either way, I do not see how such an arrangement is the most > convenient way to organize the tickets and ask questions such as > "what are the known, untriaged, or unresolved issues in v1.8.5?", > "what are the issues that didn't exist in v1.7.0 but appear in > v1.8.5?", "what are the outstanding issues around refs handling that > are the highest priority?", etc. With your arrangement of data, any > of the common questions I think of asking would require a linear > scan of a commit range, followed by an enumeration and parsing of > all the notes attached to the commits to answer. > > So I would have to say that your expectation makes even less sense > than annotating an exact buggy commit with a note saying what is > broken by it. Not less sense, because with tickets attached to the exact buggy commit one would have the same problems answering the questions above. I don't dispute that tickets and commits don't mesh, it was the reason that you gave the first time that didn't sound right. Sorry if I have wasted your time, but looking at it from the management side removed any lingering doubts for me that there might be a benefit to an integration, even if some sort of indexing or database was used.