Happy New Year to those who observe the Gregorian calendar! I'm pleased to report that I've completed all of the objectives I set for myself with respect to GNU troff formatter features and fixes.
I'd now like to announce a code freeze on all the C and C++ code in the
"master" branch of groff's Git repository. Since I'm pretty much the
only person who commits C or C++ code _to_ the repository, this
directive is aimed primarily at myself. Today I've successfully done
"make check" on Linux/amd64, Android/aarch64, and Solaris 11/sparc64.
"make check" success means that all automated tests PASS, SKIP, or
XFAIL. I won't go into details, but all 304 tests are "green".
I've applied for "Automated Upload Registration" per the GNU
Maintainers' Guide[1] so that I can upload distribution archives to
alpha.gnu.org and, later, when we finalize the release, to ftp.gnu.org.
When GNU administrators get back to me confirming my registration, I'll
proceed with tagging, signing, and uploading of 1.24.0.rc1 as soon as
possible and make an announcement per our "FOR-RELEASE" file.[2]
A few tickets attached to bug #65099, our "1.24.0 release goals and
gates" ticket are still open.[3] One involves a likely narrow audience:
users of the mdoc(7) package with the "dvi" and "lbp" devices. The
others are all documentation issues that can be worked on up to just
about the last moment before release of 1.24.0 "final".
Would you like to help?
Now is a good time to:
1. Look over the "NEWS" file and review the items presented for the
forthcoming release.[4] Respond to this list or file a Savannah bug
if you see an item that needs correction or clarification. With two
and a half years of development under our belt, this is a sizable
chunk of reading: about 900 lines (~43 kB).
2. Propose especially noteworthy items for announcement in the groff
1.24.0 release notes.
3. Build groff from Git and try it out! It's better to find bugs
before release than after. Instructions are in our "INSTALL.REPO"
file.[5]
4. If you feel made of iron, you can browse the 332 Savannah tickets
marked as fixed in the forthcoming groff 1.24.0 release.[6]
If a Savannah ticket is not depended on by bug #65099, I don't plan to
resolve it for groff 1.24.0. I _will_ make exceptions for any
regressions discovered relative to the groff 1.23.0 release; that's one
of the purposes of having a release candidate. Fixes for same, if the
problem is judged severe enough (by me, or through discussion by this
group), can override the code freeze (and necessitate an additional
release candidate).
I plan to gather feedback on RC1 for two weeks.
And maybe the best news of all? I want to release groff 1.25 this
summer, around July-ish, with no concrete release goals, just
(potential) gates. Whatever feature changes get in by that time become
"goals" retrospectively. If nothing's gating release around July 1st,
just do it. (Probably still have a release-candidate process, though.)
Then 1.26 in December 2026.
Long release cycles fatigue me (and others, I'm sure, who tire of
waiting on fixes but lack the skill or courage to backport them[7]).
Since about September 2024,[8] when I became official GNU maintainer of
groff, I've had mostly only myself to blame for the length of this one.
A devil on my shoulder constantly whispers that the release "won't be
good enough" if I don't get a significant feature change or bug fix in.
Like angels, devils are never satisfied: they always demand more of us.
Determining whether what we have is good enough is why I seek feedback.
I await yours with a hopeful face.
Regards,
Branden
[1]
https://www.gnu.org/prep/maintain/maintain.html#Automated-Upload-Registration
[2] https://cgit.git.savannah.gnu.org/cgit/groff.git/tree/FOR-RELEASE
[3] https://savannah.gnu.org/bugs/?65099
[4] https://cgit.git.savannah.gnu.org/cgit/groff.git/tree/NEWS
[5] https://cgit.git.savannah.gnu.org/cgit/groff.git/tree/ANNOUNCE
[6] https://cgit.git.savannah.gnu.org/cgit/groff.git/tree/INSTALL.REPO
[7]
https://savannah.gnu.org/bugs/index.php?go_report=Apply&group=groff&func=browse&set=custom&msort=0&report_id=225&advsrch=0&bug_id=&submitted_by=0&status_id=3&severity=0&category_id=0&assigned_to=0&summary=&bug_group_id=0&resolution_id=1&plan_release_id=107&history_search=0&history_field=0&history_event=modified&history_date_dayfd=2&history_date_monthfd=1&history_date_yearfd=2026&max_rows=50&spamscore=5&boxoptionwanted=1#options
[8] Given how hard I've churned the formatter itself with refactorings
and renamings, I wouldn't envy anyone the task of backporting a
recent GNU troff fix to 1.23.0. Even as familiar as I now feel with
the formatter's code base, I would expect some changes to be a
face-ripping experience to port backward.
[9] technically later since it's only recently that I've gotten my
account access to fencepost.gnu.org sorted out, but at the same time
I wasn't pushing GNU administrators for that until I felt the
urgency of releasing reach a certain level, so, yeah, still my fault
signature.asc
Description: PGP signature
