* Docs for base maintainer expectations?
@ 2023-07-10 18:52 Jakub Kicinski
2023-07-10 19:06 ` Conor Dooley
2023-07-11 13:52 ` Jonathan Corbet
0 siblings, 2 replies; 6+ messages in thread
From: Jakub Kicinski @ 2023-07-10 18:52 UTC (permalink / raw)
To: workflows; +Cc: linux-doc
Hi,
do we have any docs describing what's expected from folks stepping up
to maintain (small-ish) parts of the kernel like a driver or a protocol?
Experienced developers / maintainers differ like the beautiful
snowflakes that we are, but outsiders have much less familiarity
with the landscape, and frankly sometimes much less interest in
participating once they code lands.
Which makes we wonder if a simple list of responsibilities would be
useful as a baseline. I haven't spotted anything in Docs/process but
perhaps someone has a local version for their subsystem?
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Docs for base maintainer expectations?
2023-07-10 18:52 Docs for base maintainer expectations? Jakub Kicinski
@ 2023-07-10 19:06 ` Conor Dooley
2023-07-10 19:22 ` Jakub Kicinski
2023-07-11 13:52 ` Jonathan Corbet
1 sibling, 1 reply; 6+ messages in thread
From: Conor Dooley @ 2023-07-10 19:06 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: workflows, linux-doc
[-- Attachment #1: Type: text/plain, Size: 1238 bytes --]
Hey Jakub,
On Mon, Jul 10, 2023 at 11:52:39AM -0700, Jakub Kicinski wrote:
> do we have any docs describing what's expected from folks stepping up
> to maintain (small-ish) parts of the kernel like a driver or a protocol?
>
> Experienced developers / maintainers differ like the beautiful
> snowflakes that we are, but outsiders have much less familiarity
> with the landscape, and frankly sometimes much less interest in
> participating once they code lands.
>
> Which makes we wonder if a simple list of responsibilities would be
> useful as a baseline.
> I haven't spotted anything in Docs/process but
> perhaps someone has a local version for their subsystem?
Given I figure you did this on with a -rc1 based tree, which would mean
that what I wrote probably does not fit the bill, but I tried to do
something along these lines with
https://docs.kernel.org/process/maintainer-soc.html
for which my target audience was people picking up maintenance of
DT/soc drivers, which I hope there'll be a few of in RISC-V land soon...
I suggested adding things to it, like putting the trees in linux-next
etc, but review feedback suggested that was unsuited to a subsystem
specific document.
Thanks,
Conor.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Docs for base maintainer expectations?
2023-07-10 19:06 ` Conor Dooley
@ 2023-07-10 19:22 ` Jakub Kicinski
2023-07-10 19:39 ` Conor Dooley
0 siblings, 1 reply; 6+ messages in thread
From: Jakub Kicinski @ 2023-07-10 19:22 UTC (permalink / raw)
To: Conor Dooley; +Cc: workflows, linux-doc
On Mon, 10 Jul 2023 20:06:56 +0100 Conor Dooley wrote:
> On Mon, Jul 10, 2023 at 11:52:39AM -0700, Jakub Kicinski wrote:
> > do we have any docs describing what's expected from folks stepping up
> > to maintain (small-ish) parts of the kernel like a driver or a protocol?
> >
> > Experienced developers / maintainers differ like the beautiful
> > snowflakes that we are, but outsiders have much less familiarity
> > with the landscape, and frankly sometimes much less interest in
> > participating once they code lands.
> >
> > Which makes we wonder if a simple list of responsibilities would be
> > useful as a baseline.
>
> > I haven't spotted anything in Docs/process but
> > perhaps someone has a local version for their subsystem?
>
> Given I figure you did this on with a -rc1 based tree, which would mean
> that what I wrote probably does not fit the bill, but I tried to do
> something along these lines with
> https://docs.kernel.org/process/maintainer-soc.html
> for which my target audience was people picking up maintenance of
> DT/soc drivers, which I hope there'll be a few of in RISC-V land soon...
>
> I suggested adding things to it, like putting the trees in linux-next
> etc, but review feedback suggested that was unsuited to a subsystem
> specific document.
Thanks for the pointer! I haven't read it before because I assumed
it'll describe workflow and suggestions for SoC sub-tree (which it
does?) I was thinking about something way more basic, like "you are
expected to reply to bug reports", "you are expected to investigate
syzbot problems" etc. :(
IOW the SoC guide reads more like "how to get your code accepted" rather
than "what are the externally-facing responsibilities of a maintainer".
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Docs for base maintainer expectations?
2023-07-10 19:22 ` Jakub Kicinski
@ 2023-07-10 19:39 ` Conor Dooley
2023-07-10 20:46 ` Jakub Kicinski
0 siblings, 1 reply; 6+ messages in thread
From: Conor Dooley @ 2023-07-10 19:39 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: workflows, linux-doc
[-- Attachment #1: Type: text/plain, Size: 2655 bytes --]
On Mon, Jul 10, 2023 at 12:22:28PM -0700, Jakub Kicinski wrote:
> On Mon, 10 Jul 2023 20:06:56 +0100 Conor Dooley wrote:
> > On Mon, Jul 10, 2023 at 11:52:39AM -0700, Jakub Kicinski wrote:
> > > do we have any docs describing what's expected from folks stepping up
> > > to maintain (small-ish) parts of the kernel like a driver or a protocol?
> > >
> > > Experienced developers / maintainers differ like the beautiful
> > > snowflakes that we are, but outsiders have much less familiarity
> > > with the landscape, and frankly sometimes much less interest in
> > > participating once they code lands.
> > >
> > > Which makes we wonder if a simple list of responsibilities would be
> > > useful as a baseline.
> >
> > > I haven't spotted anything in Docs/process but
> > > perhaps someone has a local version for their subsystem?
> >
> > Given I figure you did this on with a -rc1 based tree, which would mean
> > that what I wrote probably does not fit the bill, but I tried to do
> > something along these lines with
> > https://docs.kernel.org/process/maintainer-soc.html
> > for which my target audience was people picking up maintenance of
> > DT/soc drivers, which I hope there'll be a few of in RISC-V land soon...
> >
> > I suggested adding things to it, like putting the trees in linux-next
> > etc, but review feedback suggested that was unsuited to a subsystem
> > specific document.
>
> Thanks for the pointer! I haven't read it before because I assumed
> it'll describe workflow and suggestions for SoC sub-tree (which it
> does?)
You did mention "local version for the subsystem", but maybe by local
you meant on their own box, rather than local to the subsystem. I
interpreted it as the latter, sorry about that!
> I was thinking about something way more basic, like "you are
> expected to reply to bug reports", "you are expected to investigate
> syzbot problems" etc. :(
Yeah, along the lines of the generic stuff it was suggested that I
should not add :)
> IOW the SoC guide reads more like "how to get your code accepted" rather
> than "what are the externally-facing responsibilities of a maintainer".
I suppose it is a bit of a mix, since the document _is_ aimed at
maintainers of platform support (there's details about sending PRs etc),
but it does contain some conventions that "code" should follow, which
they should in turn pass down to contributors.
It sounds almost as if you're looking for something to present to people
when they add themselves as an `M:` entry against a driver, for when
$company sends a patch w/ someone you've not really seen before?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Docs for base maintainer expectations?
2023-07-10 19:39 ` Conor Dooley
@ 2023-07-10 20:46 ` Jakub Kicinski
0 siblings, 0 replies; 6+ messages in thread
From: Jakub Kicinski @ 2023-07-10 20:46 UTC (permalink / raw)
To: Conor Dooley; +Cc: workflows, linux-doc
On Mon, 10 Jul 2023 20:39:40 +0100 Conor Dooley wrote:
> It sounds almost as if you're looking for something to present to people
> when they add themselves as an `M:` entry against a driver, for when
> $company sends a patch w/ someone you've not really seen before?
That is exactly the use I have in mind.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Docs for base maintainer expectations?
2023-07-10 18:52 Docs for base maintainer expectations? Jakub Kicinski
2023-07-10 19:06 ` Conor Dooley
@ 2023-07-11 13:52 ` Jonathan Corbet
1 sibling, 0 replies; 6+ messages in thread
From: Jonathan Corbet @ 2023-07-11 13:52 UTC (permalink / raw)
To: Jakub Kicinski, workflows; +Cc: linux-doc
Jakub Kicinski <kuba@kernel.org> writes:
> do we have any docs describing what's expected from folks stepping up
> to maintain (small-ish) parts of the kernel like a driver or a protocol?
>
> Experienced developers / maintainers differ like the beautiful
> snowflakes that we are, but outsiders have much less familiarity
> with the landscape, and frankly sometimes much less interest in
> participating once they code lands.
>
> Which makes we wonder if a simple list of responsibilities would be
> useful as a baseline. I haven't spotted anything in Docs/process but
> perhaps someone has a local version for their subsystem?
I think that would be good to have. We often complain about a lack of
maintainers, but we have nothing to point to telling people how they can
step up and do that.
I've tried to fill in some pieces with the documents on merging and
such, but we're missing the introduction.
Thanks,
jon
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2023-07-11 13:52 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-07-10 18:52 Docs for base maintainer expectations? Jakub Kicinski
2023-07-10 19:06 ` Conor Dooley
2023-07-10 19:22 ` Jakub Kicinski
2023-07-10 19:39 ` Conor Dooley
2023-07-10 20:46 ` Jakub Kicinski
2023-07-11 13:52 ` Jonathan Corbet
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox