On Fri, Jan 23, 2026 at 9:15 AM Alex Bennée <[email protected]> wrote:
> 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. > I've tried setting up b4 before. I'll have to try again. > Usually the most difficult thing is getting email setup so you can > git-send-email or git-publish. > The most difficult part for me is 'where the heck did google hide the password junk today' so I can turn on a password, do the submission, then kill the password. I really wish I could do OTP sometimes. > > 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. > Yea, it's not even mechanical changes. It's copying the work from one tree to another after that forked tree has been merged to the latest upstream... There's no creativity here at all. I'd be happy just having to write the commit messages... the hard part is the datamining to see who wrote things, and splitting out out function by function with dependencies for easy review... > 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. > Yea. we have a github pull request open, and we have problems from time to time, but have been swift to close ai chatbots and other slop we get. Warner > > > > Warner > > -- > Alex Bennée > Virtualisation Tech Lead @ Linaro >
