Re: [Opinions] Integrated tickets

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 11, 2014, 18:24 UTC
Message-ID: <xmqqzjbx61ew.fsf@gitster.dls.corp.google.com>
In-Reply-To: <xmqqioil7j20.fsf@gitster.dls.corp.google.com>

Junio C Hamano <gitster@pobox.com> writes:

Show 13 quoted lines

> 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 that annotating the commit as "this commit has this bug" makes much sense, though, of course ;-) But at least it would let us answer "Does this commit introduce a bug?" question, and if the annotated information also records "... and that other commit is a fix that can be cherry-picked (or merged)", that would be even better. That would allow us, when merging down the commit thusly annotated, to stop and consider either not merging (because it is known to introduce a bug) or merging with fixes also merged (because the solution is already known and recorded).