Re: [Opinions] Integrated tickets

[Holger Hellmuth <hellmuth@ira.uka.de>]

Am 11.11.2014 um 18:17 schrieb Junio C Hamano:
> Holger Hellmuth <hellmuth@ira.uka.de> 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.