From: "Rafael J. Wysocki" <rjw@rjwysocki.net>
To: Jani Nikula <jani.nikula@intel.com>
Cc: linux-kernel@vger.kernel.org,
        "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
        Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH] MAINTAINERS: clarify that "B:" is the URI where to file bugs
Date: Thu, 08 Dec 2016 00:44:59 +0100
Message-ID: <3410422.Yk2TfS5x67@aspire.rjw.lan>
User-Agent: KMail/4.14.10 (Linux/4.9.0-rc5+; KDE/4.14.9; x86_64; ; )
In-Reply-To: <87pol4xhl0.fsf@intel.com>
References: <1480939439-27947-1-git-send-email-jani.nikula@intel.com> <2136399.gq9DkmPDJp@aspire.rjw.lan> <87pol4xhl0.fsf@intel.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 3449
Lines: 79

On Wednesday, December 07, 2016 10:35:07 AM Jani Nikula wrote:
> On Wed, 07 Dec 2016, "Rafael J. Wysocki" <rjw@rjwysocki.net> wrote:
> > On Monday, December 05, 2016 02:03:59 PM Jani Nikula wrote:
> >> Different subsystems and drivers have different preferences for where to
> >> file bugs and what information to include. 686564434e88 ("MAINTAINERS:
> >> Add bug tracking system location entry type") added "B:" entry for this.
> >> 
> >> Clarify that "B:" specifies the URI for the bug tracker directly, a web
> >> page for detailed info on filing bugs, or a mailto: URI.
> >> 
> >> Fixes: 686564434e88 ("MAINTAINERS: Add bug tracking system location entry type")
> >> Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> >> Cc: Andrew Morton <akpm@linux-foundation.org>
> >> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
> >> 
> >> ---
> >> 
> >> Rafael, I just noticed the "B:" entry popped up in MAINTAINERS from
> >> 686564434e88 ("MAINTAINERS: Add bug tracking system location entry
> >> type").
> >> 
> >> I've been pushing this for some time now, and I'd sent the last patch
> >> adding this before the kernel summit discussion you refer to [1], and
> >> Andrew picked it up, along with the rest in the series. This is where
> >> the whole idea came from!
> >> 
> >> Specifying "B:" as URI lets subsystems decide whether it contains a bug
> >> tracker or something else.
> >> 
> >> [1] http://lkml.kernel.org/r/1476966135-26943-1-git-send-email-jani.nikula@intel.com
> >
> > I didn't realize that this was on the way in, sorry about that.
> >
> > That said I'm slightly concerned about the last part of the modified
> > description below.  Namely, if mailing list information is already
> > provided (the M: entry), it obviously should be suitable for reporting
> > bugs too, so I'm not sure about what the "or a mailto: URI" role is?
> 
> The absence of "B:" does not indicate that the mailing list in "M:" is
> the preferred way of reporting bugs to the driver/subsystem.

Well, if I had a development mailing, why wouldn't I want to get bug reports to it?

How useful would that be, really?

And would it actually make any sense?

To me, the meaning of B: should be where to file bugs in addition to and
not istead of the M: list.  Which is why I used this particular description in
the first place.

> I believe there are plenty of subsystems that don't really care about bugs
> reported at https://bugzilla.kernel.org; they could use this to direct
> the users to the mailing list. The subsystem could use a *different*
> list for reporting bugs. A mailto: URI could even include a preferred
> subject prefix, or Cc's [1].

But why really?

Why to complicate things more than necessary?

You seem to be claiming that the one-liner description I used is somehow
insufficient, but I'm sort of failing to see that.

> The main point of "B:" is to let the maintainers communicate their
> preferred way of receiving bug reports to the users, especially when the
> mailing list(s) or https://bugzilla.kernel.org are *not* preferred.

So here's where we differ.

It may or may not be preferred and to me it just means "there is one more
place to report bugs for this in addition to the mailing list".

Because I'm not going to refuse to respond to bug reports sent to the mailing
lists in the M: entries for the subsystems I maintain in any case.  And I sort of
can't imagine how anyone responsible enough could do that.

Thanks,
Rafael