Re: [PATCH v5 00/10] strtol(3)-related fixes

[Alejandro Colomar]

Hi Branden,

On Fri, Jul 12, 2024 at 01:48:39PM GMT, G. Branden Robinson wrote:
> Hi Alex,
> 
> At 2024-07-10T11:41:15+0200, Alejandro Colomar wrote:
> > How is that?  I would expect git-am(1) to work.
> [...]
> > What I do is on neomutt(1), while reading the email --and having run
> > neomutt(1) from the root of the git repo I want to apply the patches--,
> > press '|' and then run 'git am -s', for each mail.
> 
> The problem was that I was a doofus and managed to save only the [00/10]
> mail to the mbox, so "git am" turned its nose up at it, claiming it was
> empty of patches...which it was.

:-)

> I didn't mess with the `-s` flag, as that's not a common aspect of groff
> commit procedure at this time.
> 
> I also just ran neomutt non-interactively over the whole mbox, then
> rebased, amending the commits for style purposes.

Thanks!

> I _would_ direct your attention to this part of our HACKING document.
> 
> Documenting changes
> -------------------
> 
> The groff project has a long history and a large, varied audience.
> Changes may need to be documented in up to three places depending on
> their impact.
> 
> 1.  Changes should of course be documented in the Git commit message.
>     If a change alters only comments or formatting of source code, or
>     makes editorial changes to documentation, and does not resolve a
>     Savannah ticket, you can stop at that.
> 
> 2.  The 'ChangeLog' file follows the format and practices documented in
>     the GNU Coding Standards.
>       https://www.gnu.org/prep/standards/html_node/Change-Logs.html
> 
>     The sub-projects in the 'contrib' directory each have their own
>     dedicated ChangeLog files.  The file specifications documented there
>     are relative to the sub-project, not the root of the groff source
>     tree.  When converted to a commit message, add 'contrib/$SUBPROJECT'
>     to the entries.
> 
>     Apart from 'contrib', groff uses a single (current) 'ChangeLog' file
>     for the rest of its source tree.
> 
>     It is convenient to write the ChangeLog entry or entries first, then
>     construct a commit message from it (or them).
> [...][1]
> 
> But don't worry, I went ahead and wrote ChangeLog entries for these
> items.

Thanks!  I have a hard time writing those GNU change log entries.  The
most annoying thing when contributing to GNU projects.  :)

> Happily, all 208 automated tests that we expect to pass, passed.
> 
> You can look for these fixes in my next push.

Excellent!

> Sorry it took 4 months.

The finest stuff takes time.  :)

> I appreciate how finely sliced they were.  Small changes are a boon to
> bisection.

I only produce the finest art.  Michael taught me well.  :-}

> Regards,
> Branden
> 
> [1] https://git.savannah.gnu.org/cgit/groff.git/tree/HACKING?h=1.23.0#n46

BTW, I'm looking for help.  It's kind of related to this change...
There's a library, liba2i.  I want to package it for Debian, for being
able to use it in shadow-utils and other projects.

<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1076091>

Would you mind helping with that, if you have some time for it?


Have a lovely night!
Alex

-- 
<https://www.alejandro-colomar.es/>

signature.asc
Description: PGP signature