On Wed, Jun 26, 2024, at 18:54, David G. Johnston wrote: > On Wed, Jun 26, 2024 at 8:47 AM Nathan Bossart <nathandboss...@gmail.com> > wrote: >> 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 <j...@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.
OK, I've made the change, new patch attached. >> 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. I'll start a new separate thread about fixing the other non-canonical URLs. /Joel
v6-0001-Add-ACL-Access-Control-List-acronym.patch
Description: Binary data
