Re: [MAINTAINERS SUMMIT] Maintainer burnout

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

On Thu, Aug 17, 2023 at 03:56:43PM +0200, Miguel Ojeda wrote:
> On Thu, Aug 17, 2023 at 2:42 PM Laurent Pinchart wrote:
> >
> > I think the rules will need to be somehow flexible. As Jani mentioned,
> > there's a genuine need to be able to discuss design questions before a
> > patch series reaches perfection (experienced developers will usually
> > know that they should mark their series as RFC in that case, but
> > newcomers may not have this tribal knowledge). On the other hand, I'm
> > not going to discuss the design behind a patch series if the code is
> > intended with 3 spaces and uses CamelCase.
> >
> > Reports from automated tests, or automated reviews, should be designed
> > to help the submitter, not to scold and discourage them. I'm pretty sure
> > we can come up with wording that will be nicer to read than what I would
> > write when being tired at 3:00am, repeating the same comment for the
> > 50th time.
> 
> I think the bot should simply reply commenting on the issues it has
> found, without judging whether the patch should or should not be
> reviewed (and the bot could perhaps explicitly say so to avoid
> submitters getting discouraged).
> 
> Then, depending on what the bot finds, i.e. the amount and kind of
> issues, reviewers can decide and reply as needed. RFC patches could be
> skipped by the bot.

This defeats a little bit the point of lowering the workload of
reviewers though, if they have to review each bot report and reply to it
manually :-)

> This would already save a ton of time for reviewers, and it would help
> new contributors understand the requirements.
> 
> However, a worry that I have about such a system is if people start to
> spam unprepared patches until they pass. If that becomes a problem,
> then a possible solution could be to have a staging list for that (or
> server or similar).

-- 
Regards,

Laurent Pinchart