Hi Colin, At 2025-11-15T14:51:30-0800, Collin Funk wrote: > [GBR wrote]: > > What I took away from the 1.22.4 and 1.23.0 release cycles shows was > > that 2 weeks is about as long as we need for RC feedback. I > > remember being frustrated that holding the RC window open for a > > third week didn't seem to accomplish much. > > > > It's my first time doing this officially for groff, of course. I'm > > open to feedback or suggestions about release management. > > For Coreutils, Pádraig usually does a release snapshot around a week > before the planned release to allow people to test [1].
I noticed. :) I'm subscribed to the coreutils mailing list. I think the differences in the nature and size of the audiences for these two different projects motivates a longer evaluation timeline for groff, judging by the chronology of feedback on RCs I've seen in the past 2 groff releases (1.22.4, 1.23.0) and the last coreutils one (9.9). One thing the projects have in common is that they offer a variegated basket of command-line programs, of which some get used frequently and directly at the command line (in groff's case, _almost_ directly, via man(1)) and others of which are relatively esoteric, with few users outside of scripts. I imagine the latter to characterize numfmt(1) and afmtodit(1), for example. > Sometimes it goes well and can be released early. Other times it needs > a few more snapshots due to unforeseen bugs. The way I see it is: you gather reports of defects in the RC, categorize each (valid) issue either as requiring immediate remedy or as deferrable to the next release. If the count of "immediate remedy" defects is greater than zero, you roll another RC. If the count of deferrable defects is nonzero, you describe them in the release notes. When the count of defects demanding immediate remedy is zero, release! > Just figured I would share in case you want to try something similar, > using [email protected]. We availed ourselves of "platform-testers" in the groff 1.23.0 release cycle and its members were indeed helpful. I do plan to do so again. https://cgit.git.savannah.gnu.org/cgit/groff.git/tree/ANNOUNCE For 1.23.0, I functioned as "deputy maintainer/release manager" because our maintainer, Bertrand Garrigues, had sharply limited availability. This'll be my first time with a full bird on my lapel. Regards, Branden
signature.asc
Description: PGP signature
