[lkml]   [2016]   [Dec]   [15]   [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 12/08/2016 03:26 PM, Rafael J. Wysocki wrote:
> On Thursday, December 08, 2016 10:55:59 AM Jani Nikula wrote:
>> 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've noticed that [1] meanwhile landed as 2de2bd95f4563, so now we have
two different B: explanations in MAINTAINERS. Too bad this thread was
not resolved. Trying to CC some people from the kernel summit session
where bugzilla was discussed, keeping the rest of e-mail.


>>>>> 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?
> Yes, that's what you prefer and I'm not discussing with that.
> And you can even achieve it with the current definition of entires like this:
> M: <my devel mailing list> (no bug reports please)
> B:
> What I'm saying is that for the other subsystems that want to use B: that
> simply need not mean "preferred", but "alternative".
>> 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?
> Well, I didn't say what this implies.
> It looks like you are taking what I said as offensive somehow, but that was
> not my intention. Sorry if it sounded like that.
>> Please only speak for yourself,
> Which is exactly what I did (or at least that was my intention).
>> and don't try to decide for us.
> No, this isn't what I'm trying to do.
> I'm trying to ensure that the B: entries I added will not confuse people in the
> end after the change that you are proposing, because they are not supposed
> to mean "you should file bug reports there". They are supposed to mean
> "you can file bug reports there", or more precisely "if you file a bug report there,
> someone is actually going to take care of it".
> So basically, the introduction of B: as I did it changes the
> default for everybody (which you don't like too) into "no default", as far as
> bug tracking systems are concerned. Which addresses the problem
> with the general bug reporters' expectation that all bugs submitted to
> will be taken care of (which is not the case).
> Your proposed change takes it further to specify a preference which clearly was
> not my intention.
> I really wouldn't like all PM bugs go to the BZ, for example, because for some
> of them this is just overkill. Also if people see problems during development
> and not in production, reporting them via the M: list is more natural. And I
> could give you a couple more reasons here.
> Thanks,
> Rafael

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