Warner Losh <[email protected]> writes: (Cc sniping Paolo/Peter/Markus for AI discussion)
> On Fri, Jan 23, 2026 at 8:00 AM Alex Bennée <[email protected]> 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 <[email protected]> > > Reviewed-by: Warner Losh <[email protected]> > > --- > > [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
