Re: [PATCH v2] git.txt: mention mailing list archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hey

On Thu, 27 Sep 2018 at 08:37, Jonathan Nieder <jrnieder@xxxxxxxxx> wrote:
> Martin Ågren wrote:
>
> > --- a/Documentation/git.txt
> > +++ b/Documentation/git.txt
> > @@ -859,6 +859,9 @@ Reporting Bugs
> >  Report bugs to the Git mailing list <git@xxxxxxxxxxxxxxx> 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.
>
> Hm.  I think this encourages a behavior that I want to discourage:
> assuming that if a bug has already been reported then there's nothing
> more for the new user to add.

It was my hope that all of these could be inferred from the above text:

"I'll just drop a mail anyway."

"I wonder if there's a known solution to my issue."

"I wonder if this is known and I can provide some more details compared
to the original poster."

"Maybe I can find some thread where I can just say '+1'."

But what a language-lawyer reading says is of course a lot less relevant
than what a fresh pair of eyes (yours) reads out of the text. Thanks.

> Especially because the mailing list is not an issue tracker, this
> would make it too easy for the project to miss important bugs.
>
> Can this say something more neutral, like
>
>         See the list archive at https://public-inbox.org/git/ for
>         previous bug reports and other discussions.
>
> ?

This doesn't say "*Please* see", but it comes pretty close. Maybe
something like

  If you want to, you can see the list archive at, e.g.,
  <https://public-inbox.org/git/> for bug reports and other discussions.

>  Or if we want to encourage a particular behavior, should we say
> something about "To coordinate with others experiencing the same
> problem" or something else that encourages joining in with the
> thread instead of assuming it's taken care of?

We might also conclude that trying to delicately word-smith something
that doesn't scare off reports is tricky, and we're better off just
avoiding doing anything which might raise someone's bar for reporting an
issue. I'm leaning more and more towards "it's not broken, so don't fix
it"...

Martin




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux