Re: [RFC 5/7] Docs: Expectations for bug reporters and maintainers

[Sarah Sharp]

On Tue, Apr 16, 2013 at 09:15:06PM -0500, Rob Landley wrote:
> On 04/15/2013 12:33:34 PM, Sarah Sharp wrote:
> >Outline how often it's polite to ping kernel maintainers about
> >bugs, and
> >suggest that kernel maintainers should respond to bugs in 1 to 5
> >business days.
> 
> Is there anything in here about the four-level nature of modern
> maintainership?
> 
> Patches go from the developer, to the maintainer, to one of Linus's
> lieutenants, to Linus himself. If you submit a patch to a maintainer
> they owe you a response. The lieutenant (subsystem maintainer) owes
> that maintainer a response, and Linus (the project's architect) owes
> the lieutenant a response.

Do we want to go into this much detail in a document meant for
frustrated bug reporters?  Or perhaps we should create a separate
document about the kernel maintainer hierarchy and reference it here?

Also, please note that I'm writing this from the perspective of a driver
maintainer.  I'm not sure if we've met face to face. :)

> Linus does not owe you, personally, a response. Neither do the
> subsystem maintainers if you approach them directly with something
> that should have gone through one of the hundreds of domain-specific
> maintainers out of the Maintainers file. So the point of going to
> the right people in sequence and getting their review and
> signed-off-by lines is to ensure you don't sit there listening to
> crickets chirping while your patch is ignored. (If you approach
> Linus directly you may randomly _get_ a response, but there's no
> guarantee, and usually you won't because he's really busy.)

This file is about bug reporting, not submitting patches.  I rewrote
this file for the audience of people who would like to report a kernel
bug, but don't necessarily want to track it down and submit a patch
themselves.  Since this file isn't about submitting patches, let's focus
the discussion on bug reporters.

I agree that bug reporting should be done from the bottom up.  That's
why I tried to thoroughly explain how to find the right contact from
MAINTAINERS or get_maintainer.pl.

However, if a driver maintainer is not doing their job, is not
responding to regressions, it makes sense to escalate that up the chain.
Security holes in unmaintained code cause problems for anyone that uses
the Linux kernel, since distro kernels tend to turn nearly every config
option on.  If code is not being maintained, it may be better to remove
it, or at least mark it as depending on CONFIG_BROKEN.

If a driver maintainer isn't responding to a bug or security hole in a
timely manner, it makes sense to escalate that to the subsystem
maintainer who merges their patches.  Perhaps the driver maintainer is
on vacation, and the subsystem maintainer can tell the bug reporter
they'll have to wait.  Or maybe the driver maintainer has disappeared
completely from kernel development, and it's time someone else stepped
into their place.  Either way, the subsystem maintainer's job is to make
sure their subsystem is maintained by the driver maintainers under them.

If the subsystem maintainer doesn't respond, and it's a critical issue,
the last-ditch effort to get it fixed may need to be contacting Linus.
If there's serious code issues with a particular subsystem (like we've
seen in the past with the graphics subsystem or the ARM arch code), then
it makes sense for Linus to know about it.

TLDR version: Yes, it would be nice if bug reporters could go up the
hierarchy, but they don't have an easy way to know which subsystem
maintainers to contact.  Perhaps a new line in MAINTAINERS for the
subsystem maintainer would be helpful?

Sarah Sharp
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/