lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130418235245.GA3565@xanatos>
Date:	Thu, 18 Apr 2013 16:52:45 -0700
From:	Sarah Sharp <sarah.a.sharp@...ux.intel.com>
To:	Rob Landley <rob@...dley.net>
Cc:	linux-kernel@...r.kernel.org, linux-doc@...r.kernel.org,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [RFC 5/7] Docs: Expectations for bug reporters and maintainers

On Wed, Apr 17, 2013 at 06:49:40PM -0500, Rob Landley wrote:
> On 04/17/2013 01:23:28 PM, Sarah Sharp wrote:
> >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?
> 
> My point was that you have to contact the right person to
> semi-reliably get a response, but you're right. That's more about
> getting patches in than getting problems reproduced and diagnosed.

No worries!  I think it's really useful for patch submitters to get
their work to the right maintainers as well.  That description just
doesn't belong here. :)

> >This file is about bug reporting, not submitting patches.
> ...
> >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?
> 
> It seemed related at the time (general interacting with the
> kernel developers), but I guess not.

Ok.  Do you think the new line in MAINTAINERS would be useful as a
separate patch?  Possibly if it came from the subsystem maintainers
themselves?

> Eh, this has gone undocumented for a full decade and nobody but me's
> cared.

I think it's less "nobody but me's cared" and more "no one with
knowledge of the community is willing to write basic documentation that
is needed".  People care, just not the ones with enough expertise to
write docs.

I do care about good documentation, so I suspect you'll be getting
more patches from me in the future. :)

Any other feedback on this patchset?  If not, are you going to send
it to Linus for 3.10 or should I?

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ