Re: [Opinions] Integrated tickets

[Junio C Hamano <gitster@pobox.com>]

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.

You could arrange your "tickets" in such a way, but in general, the
way you organize your data should match how the data is expected to
commonly be accessed.

If somebody finds a bug when the version he happened to be using was
v1.8.5-9-g144d846, do you mean to attach that ticket to that exact
commit?  Or do you use v1.8.5^0 (i.e. the closest tagged version)
after making sure that it is not a commit between these two that
introduced it as a new bug?

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.