Re: [RFC PATCH v2 08/16] MAINTAINERS: be realistic about *-user

["Alex Bennée" <alex.bennee@linaro.org>]

Warner Losh <imp@bsdimp.com> writes:

(Cc sniping Paolo/Peter/Markus for AI discussion)

> On Fri, Jan 23, 2026 at 8:00 AM Alex Bennée <alex.bennee@linaro.org> wrote:
>
>  We should reflect the current status so users don't have unrealistic
>  expectations of how quickly things can get reviewed and merged.
>
>  Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
>
> Reviewed-by: Warner Losh <imp@bsdimp.com>
>  
>  ---
>
>  [AJB] I realise this is a slightly provocative patch but given how
>  widely used *-user is downstream we should be clear about the current
>  state and hopefully encourage those who rely on it to step-up.
>
> For the bsd-user case this is likely correct. We run hot and cold about being
> proactive at fixing things, and we've been somewhat cold for a while now.
>
> Part of the problem is that this submission process is very very heavyweight
> compared to other projects I contribute to. Not sure what to do about that since
> there's a reluctance to move away from it. Or alternatively, I'm somehow making
> it too hard.

We have discussed in the past allowing maintainers to directly submit
their PRs via GitLab which would be beneficial from a testing point of
view. To move this forward someone needs to propose the changes to our
policy documents so it can be discussed and merged.

However we still expect patches to go onto the mailing list for
review. The greybeards (like myself ;-) are very wedded to the inline
email workflow but if we could keep that interface while making use of
the GitLab UI for those that grew up knowing only the web maybe we could
make the project more friendly to new contributors.

I'd be interested in knowing where the pain points are for you because
modern tools like b4 make some of the grind (collecting tags and
applying patches from ML) a lot easier.

Usually the most difficult thing is getting email setup so you can
git-send-email or git-publish.

> A lot of the upstreaming work that's stalled would be ideal to tell claude to do,
> but I'm unsure the project's stance on using claude to move code, and git log
> 5 different trees to get the original author(s) of the code and make trivial compile
> tweaks.

There was some discussion at the maintainers summit about relaxing the
rules on AI submission for "mechanical" changes but it ran into the
weeds without any firm conclusion. We could certainly revisit it.

I think the concern about potential license pollution is a valid one but
this is more of a concern for "novel" changes made by AI. I've been more
relaxed on my personal FLOSS projects where I have allowed AI
contributions but made it clear that the submitter is expected to
understand whats going on. But being personal projects they are less
likely to be spammed to death by AI slop PRs which seems to be a growing
problem in the wider ecosystem.

>
> Warner 

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro