At 2026-01-01T18:57:39-0600, G. Branden Robinson wrote: > 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 should have qualified this by saying "for the planned 1.24.0 release".
I have plenty of remaining objectives...for later releases.
> 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.
Like many plans, this one didn't survive contact with the enemy.
I propose now to bust the freeze in four ways, one of which I should
have spoken of when posting, because it's only "technically" a change to
C/C++ code.
First and foremost are two important items:
1. Dave reported a regression in `ab` behavior to this list;[A] I found
that it also affects the `tm` family of requests. I'll be reverting
the refactoring change I made that produced the misbehavior.
2. A person I've never heard of before filed a private ticket reporting
a stack overflow. Their reproduction approach suggested heavyweight
tools. I was able to reproduce the problem without them. This
memory management problem appears no worse than any others we've
fixed in groff over the years; I have no reason to suspect a
security problem but, having been made aware of it, I feel obliged
to fix it. The submitter's proposed fix is simple and sensible, but
rest assured that I'll double check it. After pushing the fix, I'll
clear the "Private" bit on the ticket.[B]
Here are the others:
3. Having heard no objections to my proposal[C] to rename the `ptr`
request to `pwh` (but with a compatibility macro), I propose to
include that. I consider this change moderately important because
I've introduced several new "p"-prefixed debugging requests and
people are unlikely to enjoy their benefits if they're hard to
learn.
4. I'll have to change C/C++ code to declare the groff 1.24.0 version
number. This is an inescapable fact as groff is presently designed
(and I see little reason to change it). Relatedly, our
"FOR-RELEASE" file (which I wrote) has the update of groff's overall
copyright notice (as shown by "groff --version") as a checklist
item. I should have _mentioned_ this in announcing the freeze, but
forgot about it.
> "make check" success means that all automated tests PASS, SKIP, or
> XFAIL. I won't go into details, but all 304 tests are "green".
We have 306 now. I expect to add more. They don't violate a C/C++ code
freeze. :)
> 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]
I haven't heard back yet; I plan to email a reminder/status inquiry some
time today.
> If a Savannah ticket is not depended on by bug #65099, I don't plan to
> resolve it for groff 1.24.0.
...but I still intend to make unplanned fixes that don't bust the
freeze. For example, Alexis H. has reported some problems with the mm
macro package that I expect to fix with my next push. I've also been
correcting documentation issues, as is my wont.
> 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 still expect to hew to this; since I can't upload an rc1 distribution
archive, I haven't tagged rc1 yet.
I'll quote/repost the following. I've modestly updated and corrected it
(mainly in the hyperlink department).
> 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.[5]
>
> 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.[6]
>
> 4. If you feel made of iron, you can browse the 332 [now 335 --GBR]
> Savannah tickets marked as fixed in the forthcoming groff 1.24.0
> release.[7]
>
> I plan to gather feedback on RC1 for two weeks.
[...]
> [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
Thanks to those who have done #3 above and reported problems!
Let me know what you think.
Regards,
Branden
[A] https://savannah.gnu.org/bugs/?67890
[B] https://savannah.gnu.org/bugs/?67899
[C] https://lists.gnu.org/archive/html/groff/2025-12/msg00074.html
https://savannah.gnu.org/bugs/?67880
signature.asc
Description: PGP signature
