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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html