On Tue, Jun 30, 2026 at 9:18 PM David Jencks <[email protected]> wrote: > > I don’t actually work on maven, so feel free to discount my opinion. I don’t > really understand your point of view. I doubt Elliotte has an infinite amount > of time to work on maven, so I think he takes vote threads as a trigger to > look around for possible problems and improvements in the release candidate > and generally asks, “are any of these important enough to redo the release?” > While this might seem annoying or distracting, upon reflection I think this > is a valuable contribution. While I think this is the first time he’s used AI > to look for problems, I think it’s conceptually similar to many of his past > posts on vote threads. >
Pretty much. I don't always have the time or detailed knowledge to judge if a given problem is a blocker or not, so I'll post it to let whoever's actively working on the code decide. If I do think it's a blocker, I will vote -1, but since my vote isn't binding that's not especially important. Like everyone else, I'm still figuring out this LLM stuff, and understanding what it can do and how to use it. It does seem to be finding real and useful bugs no one else has noticed. How many and how serious they are depends a lot on the quality of any given repo. Sometimes the LLM only notices trivial things and false positives because it's a good project with extensive test coverage and there's nothing else to find. Sometimes it finds real whoppers that aren't the same issues found by traditional static analysis tools. It has occurred to me that I might be able to prompt OpenCode to actually file individual issues and possibly add PRs to fix the issues. I'll give that a whirl on the next repo I look at. And one general meta point, multiple folks here (not pointing at any one person because this really is a general issue) tend to assert their personal practices for software development and project management as the official way we do things, when in fact it's no such thing. It's common to receive directly contradictory instructions from different project members about how I should do something. Even if I try to align work with people's individual preferences, I find I can't remember who wants X and who wants ~X. I've actively stopped merging dependency upgrades because it was near 100% guaranteed that no matter how I did it, someone would complain and tell me I was doing it wrong. Otherwise, unless the request is actually a de facto or de jure practice across the team, I'll take these things under advisement but I don't consider them normative. -- Elliotte Rusty Harold [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
