On Thu, Jun 04, 2026 at 03:03:06PM +0200, Bruno Haible wrote: > Pavel Cahyna wrote: > > Perhaps you could start by providing > > some commits to analyze (some of them that contain known regressions, > > some of them that don't - without indicating which one is which) to have > > a smaller set than e.g. all commits since 2026-01-01? > > Makes sense. > > Try these commits: > 6aae65332edc58970c0dc287b28c8f1f6250282a > 17dc60e624cd6fc3491f9cb002f760d60e66ce8b > 53d4558960659ba7c4e9e2757bfb0977a5027fae > f6894c646a4f2f544209faf8ecb57ba64d9b8238
Thanks, I started working on it and I expect to report the results tomorrow. > I guess that in the beginning, the analyses will show many false alarms > and few good reports. The art will be to improve this ratio over time, > by incorporating gnulib specific rules in the prompt(s). I think it depends in what is the goal. If the goal is to review all incoming patches for conformance to project standards, then probably yes. But if you want to review already accepted commits for functionality regressions (and that's the case at least for this initial test), then we probably don't care about less important (e.g. style) issues and therefore we can simply filter them out. Perhaps gnulib specific rules are not needed as much then, since what constitutes a functionality regression is much less subjective (and less project-specific) than what is acceptable according to particular style conventions. Regards, Pavel
