On Mon, Jun 29, 2026 at 2:43 PM Mark Thomas <[email protected]> wrote: > > On 29/06/2026 11:24, Rémy Maucherat wrote: > > On Mon, Jun 29, 2026 at 11:51 AM <[email protected]> wrote: > >> > >> This is an automated email from the ASF dual-hosted git repository. > >> > >> markt-asf pushed a commit to branch main > >> in repository https://gitbox.apache.org/repos/asf/tomcat.git > >> > >> > >> The following commit(s) were added to refs/heads/main by this push: > >> new c19098eeca Update link. Remove default - a Realm is always in a > >> Container. > >> c19098eeca is described below > >> > >> commit c19098eeca424242d99f814002246a9dae864766 > >> Author: Mark Thomas <[email protected]> > >> AuthorDate: Mon Jun 29 10:50:39 2026 +0100 > >> > >> Update link. Remove default - a Realm is always in a Container. > > > > Ok. I did not realize this could have been documented, sorry for the > > trouble. > > No problem. > > Your code reviews are finding lots of edge cases (and some not so edge > cases) and it is great to get them fixed before users find them. My only > concern is that you go slowly enough that I can keep up with the reviews > as well as making progress on other things (like HTTP QUERY support). > > I can keep up with the current pace but I don't really have any headroom > for other issues. > > Have you tried running the proposed changes through a different AI? My > current experience is that GPT-5.5 finds the more significant > regressions but missing some minor issues. Opus 4.8 finds more > regressions but also includes some false positives in the results.
Sorry again for the extra trouble. OTOH you don't really have to review everything since the leftover is edge cases of edge cases which would presumably be caught by further code reviews down the line. I've always thought iterating for a while seems the best plan right now given how LLMs behave. The most important IMO is to catch regressions. In this particular case, this is SSI so although I wanted to fix the issues (they were looking rather legitimate), I have no knowledge about it. So the process right now is: - Go through my reports and determine if the issues are legitimate (unfortunately the majority are, so that's a lot of issues). - If so, try to look at how reasonable any proposed fix looks. - Apply fix, run testsuite. - Look at existing code coverage, try to see if a test would be useful. If the new code is covered by the existing tests, this makes me more confident (this was the case here). - Go through a review of the patch. There's one problem here: I use the same model since it's convenient. Here, I'm mostly worried about regressions, since this is about fixing minor issues. I'm constantly thinking about ways to improve the process. I think I have two different models I can reasonably use for the patch review, which could improve things. Rémy --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
