[lkml]   [2016]   [Dec]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] MAINTAINERS: clarify that "B:" is the URI where to file bugs
On Thu, 08 Dec 2016, "Rafael J. Wysocki" <> wrote:
> On Wednesday, December 07, 2016 10:35:07 AM Jani Nikula wrote:
>> On Wed, 07 Dec 2016, "Rafael J. Wysocki" <> 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 <>
>> >> Cc: Andrew Morton <>
>> >> Signed-off-by: Jani Nikula <>
>> >>
>> >> ---
>> >>
>> >> 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]
>> >
>> > 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; 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 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.

Over at drm/i915 we *prefer* to have the bugs reported at Not the mailing list, not at The last two happen to be the current
default, and we prefer not to use either of them.

Why do you think you know better than us what we prefer?

Why do you think our *preference* for bugs reported at fdo makes us
irresponsible and/or refuse to respond to bugs on the mailing list?

Please only speak for yourself, and don't try to decide for us.


Jani Nikula, Intel Open Source Technology Center

 \ /
  Last update: 2016-12-08 09:56    [W:0.141 / U:1.724 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site