Thread (1 message) 1 message, 1 author, 2016-06-15

Re: [Opinions] Integrated tickets

From: Junio C Hamano <hidden>
Date: 2016-06-15 23:02:54

Junio C Hamano [off-list ref] writes:
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).
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help