Re: [RFC] Maintainer entry profile/contributor guide for IIO

On Mon, 17 Aug 2026 13:50:29 -0500
"Maxwell Doose" <[email protected]> wrote:

> On Mon Aug 17, 2026 at 4:18 AM CDT
> Joshua Crofts <[email protected]> wrote:
> 
> > Hi all,
> >
> > I was browsing lore and checked out the ksummit mailing list, where the
> > topic about guiding new contributors arose [1]. New contributors tend to
> > make the same mistakes when sending patches, causing reviewers to point
> > these out all the time over and over again. For IIO, this is definitely the
> > case (I myself send an email telling people not to send a v2 in reply to a
> > v1 several times a week). Other subsystems have a "Maintainer entry profile"
> > that contains subsystem-specific process info (DAMON for example [2]) and 
> > (sometimes even [3]) a document describing the code style of the subsystem
> > (this would be a great place where to mention things like not using
> > kernel.h in new drivers etc.). I'm happy to create both of the documents
> > but it's always great to hear other people's ideas! 
> >  
> 
> Took a look at [1] and it looks like these are issues across multiple
> mailing lists so maybe we should add these to the main
> submitting-patches documentation? And then for other IIO-specific things
> we can put those in a maintainer entry profile.

Fair, the "don't reply with a v2 to a v1" comment was a bit off considering
I was mainly talking about IIO specific documentation, however having a central
document (or documents) of sorts for the IIO code style and process is a nice
thing to have, I'm sure even the most seasoned reviewers forget stuff occasionally.

> 
> > Second of all, the idea of having a bot that would automatically detect new
> > contributors (i.e. the email they're submitting the patch with doesn't show
> > up in `git log --author`) and send an email reminding them of the basic rules
> > (while also referring to the entry profile mentioned above) sounds like a
> > great idea, but of course hosting and maintaining are pain points.
> >  
> 
> Hm...this one is more difficult. I guess a good first question to ask
> would be "can this be hosted on kernel.org infastructure?" But maybe we
> can also ask Greg KH about how he does his automated bot.

From what I gathered, kernel.org doesn't really provide infrastructure for this
type of stuff :( If you look at [1] you see that netdev got overloaded with patches
so they made their own bot for this exact purpose. One could just spin up a
Docker container that periodically pulls from lore using lei and runs a git log
with the author's email against mainline/testing/togreg.

I believe it was David who originally proposed an IIO bot [1], primarily for code
inspection.

[1] https://lore.kernel.org/all/[email protected]/

-- 
Kind regards,
Joshua Crofts