| Message ID | 6319b34fc808ff6d8948e59f381cc5342b9ef17d.1537375332.git.martin.agren@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | git.txt: mention mailing list archive | expand |
Martin Ågren <martin.agren@gmail.com> writes: > In the "Reporting Bugs" section of git(1), we refer to the mailing list, > but we do not give any hint about where the archives might be found. And why is it a good idea to give that information in Reporting Bugs section? Are we asking the bug reporters to look for similar issues in the archive before they send their message? If so, I think that we should be explicit about it, too. Otherwise, the list archive location would look like an irrelevant noise to those who wanted to find the address to report bugs to. For example, we can say something like this: > Report bugs to the Git mailing list <git@vger.kernel.org> where the > development and maintenance is primarily done. You do not have to be > subscribed to the list to send a message there. +If you want to check to see if the issue has +been reported already, the list archive can be found at +<https://public-inbox.org/git/> and other places.
On Thu, 20 Sep 2018 at 21:07, Junio C Hamano <gitster@pobox.com> wrote: > > Martin Ågren <martin.agren@gmail.com> writes: > > > In the "Reporting Bugs" section of git(1), we refer to the mailing list, > > but we do not give any hint about where the archives might be found. > > And why is it a good idea to give that information in Reporting Bugs > section? Are we asking the bug reporters to look for similar issues > in the archive before they send their message? If so, I think that Your guess is correct, sorry for forcing you to make one. > we should be explicit about it, too. Otherwise, the list archive > location would look like an irrelevant noise to those who wanted to > find the address to report bugs to. > > For example, we can say something like this: > > > Report bugs to the Git mailing list <git@vger.kernel.org> where the > > development and maintenance is primarily done. You do not have to be > > subscribed to the list to send a message there. > +If you want to check to see if the issue has > +been reported already, the list archive can be found at > +<https://public-inbox.org/git/> and other places. I think that one reason I avoided spelling out why giving the archive location was a good thing to do, was that I didn't want to begin a huge list of "please do this and that", scaring away potential bug reporters. I think your "If you want to" solves that problem very nicely. I'll wrap this up later today. Martin
On Wed, Sep 26, 2018 at 10:05:29AM +0200, Martin Ågren wrote: > On Thu, 20 Sep 2018 at 21:07, Junio C Hamano <gitster@pobox.com> wrote: > > > > Martin Ågren <martin.agren@gmail.com> writes: > > > > > In the "Reporting Bugs" section of git(1), we refer to the mailing list, > > > but we do not give any hint about where the archives might be found. > > > > And why is it a good idea to give that information in Reporting Bugs > > section? Are we asking the bug reporters to look for similar issues > > in the archive before they send their message? If so, I think that > > Your guess is correct, sorry for forcing you to make one. > > > we should be explicit about it, too. Otherwise, the list archive > > location would look like an irrelevant noise to those who wanted to > > find the address to report bugs to. > > > > For example, we can say something like this: > > > > > Report bugs to the Git mailing list <git@vger.kernel.org> where the > > > development and maintenance is primarily done. You do not have to be > > > subscribed to the list to send a message there. > > +If you want to check to see if the issue has > > +been reported already, the list archive can be found at > > +<https://public-inbox.org/git/> and other places. > > I think that one reason I avoided spelling out why giving the archive > location was a good thing to do, was that I didn't want to begin a huge > list of "please do this and that", scaring away potential bug reporters. > I think your "If you want to" solves that problem very nicely. I'll wrap > this up later today. Yeah. This is a tricky issue in my mind. On the one hand, getting a deluge of duplicate bug reports is a burden for people who actively read and respond to the list. On the other hand, imposing such a burden on bug reporters is a detriment to Git users, who wouldn't benefit from the fixes that would come with good bug reports. But I think that the above is only a problem if bug reporters are consistently ignoring this advice. I don't think they will, since the barrier to entry is already quite high (e.g., sending email is more foreign to some than opening a GitHub issue, say). So, I think that the suggestion above is a good one, since I believe we'd rather get some bad bug reports than no bug reports at all. Thanks, Taylor
diff --git a/Documentation/git.txt b/Documentation/git.txt index 74a9d7edb4..40eaccafb2 100644 --- a/Documentation/git.txt +++ b/Documentation/git.txt @@ -858,7 +858,9 @@ Reporting Bugs Report bugs to the Git mailing list <git@vger.kernel.org> where the development and maintenance is primarily done. You do not have to be -subscribed to the list to send a message there. +subscribed to the list to send a message there. The mailing list archives +are available at <https://public-inbox.org/git/>, +<http://marc.info/?l=git> and other archival sites. Issues which are security relevant should be disclosed privately to the Git Security mailing list <git-security@googlegroups.com>.
In the "Reporting Bugs" section of git(1), we refer to the mailing list, but we do not give any hint about where the archives might be found. Copy the text from README.md on this to give potential reporters an honest chance of finding out whether their bug has already been reported. Signed-off-by: Martin Ågren <martin.agren@gmail.com> --- Documentation/git.txt | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)