Just to follow up.... On Fri, Jan 23, 2026 at 3:14 PM Warner Losh <[email protected]> wrote:
> > > On Fri, Jan 23, 2026 at 9:58 AM Daniel P. Berrangé <[email protected]> > wrote: > >> On Fri, Jan 23, 2026 at 08:12:33AM -0700, Warner Losh wrote: >> > 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]> >> >> snip >> >> > 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. >> >> The critical thing we don't want is such tools making changes to the >> contents of source files. >> >> Automating the moving around of files is a non-issue. >> >> The use of AI for writing commit messages is arguably in scope of QEMU's >> AI policy given that is part of "the contribution", but it is less serious >> there, since commit messages don't have a copyright implication on what we >> host & distribute. >> >> More important is that the commit messages are accurate and well written. >> LLMs have a tendancy to be overly verbose about irrelevant stuff, and of >> course the well known danger of hallucinating nonsense. IME that makes it >> challenging to benefit from an LLM, due to review & re-writing overheads >> you then incurr to validate and fix their output. >> > > Yea, the commit messages llm would generate is 'do function X' and I'd then > fill it in from there, changing everything except X. > > >> I'd be wary of relying on an AI to extract and report on authorship of >> code. Accuracy is important there since it implies copyright ownership >> associations. Likewise a Signed-off-by tag should be added by humans >> only since it is a statement they are complying with the DCO policy. >> > > I'd be verifying everything done. Verification is relatively easy, > extraction is > the hard part. And the range of people it could be is tiny, so I'd know if > it > was making stuff up, or had gone off the rails... And I'd have it add > something > like 'Supposed-author: ' that I'd change once I verified it. That's ugly > grunt work, > but ugly grunt work I can do in an hour or two rather than the dozens of > hours > it usually takes me to do the extraction... > So, claude looks likeit's doing a passing fair job at this work. I plan on submitting a patch series for one of the minor files in the coming weeks (depending on how much time I can find to work on it). Any guidance you can give me up front? Before I submit, I plan on auditing every single change to make sure claude didn't introduce anything that's not in bsd-user's blitz branch. Make sure the authors are correct to the same level that I've been doing so far. And make sure I've rewritten all the commit messages. One question I have, should include these lines 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]> it is adding to the commit messages or not? Claude generated this as a series of commits from the blitz branch to the master branch, but didn't actually generate any new code or fix any bugs. I'm happy to include them if you want, but also am weary about setting of a knee-jerk reaction that would be unhelpful since it's responding to the 'slop' worries and not the merits of the current work. Comments? Warner
