On Fri, Aug 28, 2026 at 4:11 PM Daniel Gustafsson <[email protected]> wrote:
> > On 28 Aug 2026, at 20:53, Corey Huinker <[email protected]> wrote: > > > While commits are still coming in that would fit the v19 window, it may > be > > easier for the committer to manually scan those commits against the > existing > > list (whichever they choose to use) than wait for me to re-generate the > list, > > though I'm happy to do so if requested. > > > It seems like a safer approach to regenerate the data based on the commits > which have happened since you ran the report last. I've got nothing against continuing to re-run the process (it's an ETL, really) periodically as we get closer to release date. It runs fairly fast across the timeline in question (REL_18_STABLE..REL_19_STABLE). The issue was more with the clutter of re-posting lists that haven't changed much if at all. Would a once-a-week cadence make sense? I'll include an as-of-commit-hash freshness date on each one. As a side note, what I've written doesn't really work incrementally. It scans the commits for "perfect" tags, then uses those as a basis for sorting out the proper attribution for less well-formed tags, and names that weren't in tags at all, regardless of whether those proper tags happened before or after the ambiguous one. So it's possible for an old commit to "learn" from a new one, hence just re-running the whole thing.
