On Mon, 2016-02-08 at 14:16 -0800, Junio C Hamano wrote: > Jeff King <peff@xxxxxxxx> writes: > > > FWIW, as the person who wrote that section, I think that is a good > > addition. We do have a link to Simon Tatham's bug-reporting guide, but > > this is a good place to put project-specific advice. > > > > In addition to "try it on next" you may want to also mention "try it on > > the latest version of git". That is another frequently given pointer to > > bug reporters. Trying "next" is obviously a superset, but I suspect > > trying a released version may be an easier first step for some people. > > Yes, definitely. > > I agree that testing with the latest released version would > typically be much easier to end users than building from the source. > It would reduce the need for "Ah, that's ancient issue, we know it > was fixed a few releases ago." responses by us; I do not recall many > of such responses in the recent history on the list, though. > > For the ones who are more into the spirit of helping each other who > can build from the source to help us even more, checking 'master' > and finding regressions before it gets too late is a very good > thing. Checking 'next' and confirming an upcoming fix is equally > valuable. OK, so this testing is an encouragement, not an expectation per se, even if bug reports may be less likely to get attention without it (I'm not familiar with the degree to which this may have been the case recently). See my revised proposed text here: https://github.com/git/git-scm.com/pull/676/files I'll send an analogous patch for the git(1) man page in a moment. I left a mention of providing feedback on pending fixes but thought it would be too much to go into the details of how to identify whether there is a pending fix. Is this sensible? Matt -- 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