Re: groff 1.23.0.rc2 readiness

[John Gardner]

Hi Branden,

I'm running out of things I can think of to do before RC2.
>

Please consider #62494 <https://savannah.gnu.org/bugs/?62494> ASAP.
Otherwise, it's going to piss a lot of users off.

Regards,
— J

On Thu, 26 May 2022 at 13:56, G. Branden Robinson <
g.branden.robinson@gmail.com> wrote:

> Hi Bertrand,
>
> I'm running out of things I can think of to do before RC2.
>
> Below, I'll excerpt the FOR-RELEASE file and annotate it.
>
> * Increment the version number.  groff requires an explicit three-part
>   version, major.minor.revision, due to the .Y register.
>
> Can you do the "git tag 1.23.0.rc2"?  As I understand it, that is all
> that is required for this step.  (Maybe I should move it to be later in
> the file.)
>
> * Update font description files that we generate from external data and
>   provide with our source distribution.
>
>     Directory  Format                  Tool
>     ---------  ------                  ----
>     devX*      X11 core/server font    xtotroff
>
>   The make(1) target "maintainer-font-descriptions" produces these font
>   descriptions.
>
> This was "done" after this following commit, but it caused no changes to
> in-tree files.
>
>         commit 3c82cbbfe5c378f8fc274b93cce28624b19a1b8a
>         Author: G. Branden Robinson <g.branden.robinson@gmail.com>
>         Date:   Sun Feb 27 21:18:19 2022 +1100
>
> * Retrieve current versions of UnicodeData.txt[1] and the Adobe Glyph
>   List (AGL)[2], and use them with
>   src/utils/afmtodit/make-afmtodit-tables to update
>   src/utils/afmtodit/afmtodit.tables.
>
>   [1] E.g., <https://www.unicode.org/Public/13.0.0/ucd/UnicodeData.txt>.
>       Check for the latest _released_ version of Unicode at the time.
>       Data for the forthcoming release may be available.
>   [2] <https://github.com/adobe-type-tools/agl-aglfn/blob/master/\
>       glyphlist.txt>
>
>         commit f04365c2b33e0d031e509bc4e739eaf3b28b3af0
>         Author: G. Branden Robinson <g.branden.robinson@gmail.com>
>         Date:   Wed May 25 21:13:35 2022 -0500
>
> * Update the 'gnulib' sub-module to the latest version and the
>   corresponding required commit hash identifier in 'INSTALL.REPO'.
>
>         commit f55d8f418935e4f63f2a54ea2fa99e25b42767f8
>         Author: Bertrand Garrigues <bertrand.garrigues@laposte.net>
>         Date:   Sat Apr 23 17:50:07 2022 +0200
>
> * Update the release version number where it is hard-coded.
>   + NEWS
>   + BUG-REPORT
>   + arch/mingw/grap2graph.cmd
>   + doc/groff.texi (multiple occurrences)
>   + doc/webpage.ms
>
>         commit 5224da3e11cf586c02239b963e724425e5de4689
>         Author: G. Branden Robinson <g.branden.robinson@gmail.com>
>         Date:   Sun Oct 25 14:18:09 2020 +1100
>
> * If the major or minor version number is being incremented, split off
>   a historical ChangeLog file.
>
>         commit c11995df168e38d4d6dddf11c163951a15104f34
>         Author: G. Branden Robinson <g.branden.robinson@gmail.com>
>         Date:   Fri Feb 19 08:22:07 2021 +1100
>
> * Update in 'src/roff/groff/groff.cpp' the 'printf' that displays the
>   copyright.
>
>         commit e70b435374060d0e8a7de115899193fadecc9d3f
>         Author: G. Branden Robinson <g.branden.robinson@gmail.com>
>         Date:   Wed May 25 21:36:51 2022 -0500
>
> * Update the copyright year with 'update-copyright.sh'.
>
> I haven't done this yet; I'm a little uneasy with the practice, and in
> the past it has been error-prone so I'm apprehensive about doing it.  I
> try to update copyright years by hand when I make a change to a file
> that I think of as being substantive enough to constitute "original
> expression", but that is of course a highly subjective standard.
> Regardless, even if the script isn't run, we still won't have many if
> any truly stale dates.  Can you do this one too, if you think it's
> warranted?
>
> ----
>
> I think an announcement email for RC2 should include the portion of the
> 'NEWS' file up to the last release.  Alternatively, if you'd like to
> excerpt the items you consider most noteworthy, that would be fine too.
>
> I have several ideas for release notes which would similarly excerpt
> 'NEWS' and include some statistical information on commits,
> contributors, and resolved Savannah tickets (inspired by other
> announcements I've seen on the info-gnu list), but I don't want to gate
> the RC on that.  I can work on it while feedback on RC2 comes in.
>
> Our RC1 announcement[1] included building instructions.  I've updated
> (and in the first 2 cases, created) all of the following top-level
> documentation files recently.
>
>         FOR-RELEASE
>         HACKING
>         INSTALL.REPO
>         INSTALL.extra
>         LICENSES
>         NEWS
>         PROBLEMS
>         README
>
> Of particular interest for an RC are the updated building instructions.
> As part of that I've documented how to build from the snapshot archives
> that Savannah/cgit create on demand from any commit.
>
> I should also note that Bjarni suggested that we CC the GNU
> platform-testers list on our future beta/RC announcements[2].  If you
> like this idea and it works out, I can add this step to "FOR-RELEASE".
>
> If there is something you'd like me to do to facilitate RC2, please
> don't hesitate to ask.
>
> Regards,
> Branden
>
> [1] https://lists.gnu.org/archive/html/groff/2020-11/msg00068.html
> [2] https://savannah.gnu.org/bugs/?61939
>