[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 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 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)

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.


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