On Wed, Jun 26, 2024 at 07:58:55AM -0700, David G. Johnston wrote: > On Wed, Jun 26, 2024 at 7:52 AM Joel Jacobson <joel@compiler.org> wrote: >> Want me to fix that or will the committer handle that? >> >> I found some more similar cases in acronyms.sgml. > > Given this I'd be OK with committing as-is in the name of matching existing > project style. Then bringing up this inconsistency as a separate concern > to be bulk fixed as part of implementing a new policy on what to check for > and conform to when establishing acronyms in our documentation. > > Otherwise the author (you) should make the change here - the committer > wouldn't be expected to know to do that from the discussion.
If I was writing these patches, I'd create a separate 0001 patch to fix the existing problems, then 0002 would be just the new stuff (without the inconsistency). But that's just what I'd do; there's no problem with doing it the other way around.
Agreed, if Joel wants to write both. But as the broader fix shouldn't block adding a new acronym, it doesn't make sense to insist on this approach. Consistency makes sense though doing it the expected way would be OK as well. Either way, assuming the future patch materializes and gets committed the end state is the same, and the path to it doesn't really matter.