Re: groff maintainership, release, and blockers

[Dave Kemper]

On 8/26/22, G. Branden Robinson <g.branden.robinson@gmail.com> wrote:
>     #58930 take baby steps toward Unicode
>       Core 5 - Blocker Need Info gbranden barx 2020-08-10
>
>       Like the previous, this is a reminder to myself to decide how I
>       want to document something.  Once that is addressed, the ticket
>       itself will remain open, with a lower severity.

I opened this as an umbrella ticket for four minor issues that in
hindsight should have been four separate tickets.  It was made a
Blocker in response to discussion about commit 86b99bdb
(http://git.savannah.gnu.org/cgit/groff.git/commit/?id=86b99bdb),
which partially handles \[u2011] (Unicode's NON-BREAKING HYPHEN) for
PostScript and PDF devices.

Discussion in the ticket (related to its Blocker status) is about
whether to leave the aforementioned commit in place or revert it.
This discussion doesn't mention anything about documentation.

If your interpretation is that this amounts to a decision between
reverting the commit and documenting its limitations, I think this
tips the scales more toward reversion: that puts us back to where
1.22.4 (and previous releases) were (rejecting U+2011 and notifying
the user so), whereas documenting the limitations requires extra
effort to explain what is essentially a stopgap measure.

If that's NOT your interpretation, could you clarify what the blocking
documentation issue is?



On 8/27/22, Ingo Schwarze <schwarze@usta.de> wrote:
> Even though this is documentation only, i recommend resolving it before
> RC3 because switching back and forth in terminology in three consecutive
> releases could be regarded as awkward:
>
> #62816 rename the \& escape...again

I agree with this.  Since it's likely the current (in git) name will
change again but hasn't yet appeared in any released documentation, it
may as well get nailed down before it goes out into the world.