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:
signature.asc
Description: PGP signature
