git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: Neal Kreitzinger <neal@rsss.com>, git@vger.kernel.org
Subject: Re: how to determine oldest supported version of git
Date: Thu, 2 Feb 2012 14:49:37 -0500	[thread overview]
Message-ID: <20120202194937.GB9246@sigill.intra.peff.net> (raw)
In-Reply-To: <20120202192124.GA19873@burratino>

On Thu, Feb 02, 2012 at 01:23:40PM -0600, Jonathan Nieder wrote:

> However, in my experience people interested in product lifetimes more
> often mean "versions the vendor will respond to bug reports about"
> rather than "versions getting updates".  If you have discovered a bug
> in an old version of git, even if it is only a couple of major
> releases ago, a good debugging strategy is almost always to try with
> the newest release and see if it still exhibits the bug.  If you don't
> try that, people on this list might just try it themselves.  If it
> doesn't affect recent releases, I would not be surprised if people on
> this list do not necessarily care much.  One can more easily interest
> me at least by pointing out which regression is making it hard to
> upgrade instead.

Agreed. It is very annoying to have somebody report a bug, I (or another
dev) spends time trying to reproduce, and then we find out that it was
actually fixed a year ago.

However, I am much happier if a submitter does that leg-work themselves,
and posts to the list something like:

  I am using version a.b.c. It has bug $FOO, which was fixed by $COMMIT
  and released in d.e.f [or even "I tried d.e.f and it does not exhibit
  the bug"]. This bug fix should get cherry-picked back to a.b.c,
  because {it is more important than usual for reason X, upgrading past
  a.b.c is not feasible for reason Y, etc}.

Nobody wastes time tracking down the already-fixed bug, and it's
relatively easy to decide whether the cherry-pick is worth the effort
based on the reasoning given.

I know not everybody is capable of complex bisection or writing a
succinct test case. But they can at least try to reproduce with the
latest version and convert "there's a bug in git" to "there's a bug in
this old version of git".

-Peff

  reply	other threads:[~2012-02-02 19:50 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-02 16:46 how to determine oldest supported version of git Neal Kreitzinger
2012-02-02 19:23 ` Jonathan Nieder
2012-02-02 19:49   ` Jeff King [this message]
2012-02-03  4:52 ` Junio C Hamano
2012-02-03 20:19   ` Neal Kreitzinger
2012-02-10 19:42   ` Junio C Hamano
2012-02-15  5:36     ` Jeff King
2012-02-15  6:36       ` Junio C Hamano
2012-02-15  9:15         ` Jeff King
2012-02-15 18:34         ` Jonathan Nieder
2012-02-15 18:44           ` Jonathan Nieder

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=20120202194937.GB9246@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=jrnieder@gmail.com \
    --cc=neal@rsss.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).