All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Holger Hellmuth <hellmuth@ira.uka.de>
Cc: Fredrik Gustafsson <iveqy@iveqy.com>, git@vger.kernel.org
Subject: Re: [Opinions] Integrated tickets
Date: Tue, 11 Nov 2014 10:24:23 -0800	[thread overview]
Message-ID: <xmqqzjbx61ew.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <xmqqioil7j20.fsf@gitster.dls.corp.google.com> (Junio C. Hamano's message of "Tue, 11 Nov 2014 09:17:59 -0800")

Junio C Hamano <gitster@pobox.com> 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).

      parent reply	other threads:[~2014-11-11 18:24 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-05 12:44 [Opinions] Integrated tickets Fredrik Gustafsson
2014-11-06  5:53 ` Jeff King
2014-11-06 18:45 ` Junio C Hamano
2014-11-11 12:46   ` Holger Hellmuth
2014-11-11 17:17     ` Junio C Hamano
2014-11-11 18:15       ` Holger Hellmuth
2014-11-11 18:24       ` Junio C Hamano [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqzjbx61ew.fsf@gitster.dls.corp.google.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=hellmuth@ira.uka.de \
    --cc=iveqy@iveqy.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.