Follow-up Comment #8, bug #67939 (group groff): At 2026-01-31T20:05:15-0500, Dave wrote: > I agree that multiple tickets are unnecessary. But you can include > multiple patches in the same ticket, and these changes strike me as > warranting separate commits. However, that ruling is ultimately above > my pay grade, so I defer to those with commit privileges.
As a person with commit privileges, I agree with the principle.
Here are some thoughts on change management.
As a rule we should try to slice commits (and more generally, "change
sets") finely, as if any given distinguishable change might have to be
reverted some day.
Combination can be warranted where multiple changes are logically
coupled. A test for this is: would you not revert one change _without_
reverting another, because failing to handle both together would break
the build, cause automated test failures, leave a piece of groff-
specific terminology undefined in documentation, or similar?
Sometimes logically coupled changes get committed separately anyway for
reasons of code organization, like "here's a change to the formatter"
and "here's a change to the mom(7) package to exercise the previous
change".
In those scenarios, the wise course of action is to _sequence_ commits
such that breakage (of the build, of test scripts, of the brain of
the documentation peruser) is avoided.
Rarely, a change (or set of changes) requires staging, because there's
no way to achieve the aforementioned sequencing while not "breaking"
anything without adding in scaffolding that wouldn't otherwise be
necessary.
For example, consider the scenario of replacing a GNU _troff_ request,
and let's imagine that for some reason it is undesirable to support a
transition period or compatibility wrapper or alias. Just, bam, old
request becomes undefined and new one springs into being. (I propose
this example because it is easy to think about, not because it's a
plausible scenario or would be wise development practice.[1])
Furthermore let's imagine that _mom_(7) uses this request.
The scenario poses a challenge. Peter is the author, maintainer, and
gatekeeper of the "om.tmac" file. Let's imagine that I haven't done
prior coordination with him (another example of dubious project
management for the sake of example) and that he would prefer to perform
the rename himself. (Perhaps he has examples or documentation that
could be usefully enhanced to exercise the new request.)
In that case the "scaffolding" I'd erect would include an alias (if the
request's argument semantics didn't change) or a wrapper macro (if they
did). I'd sequence that change first (perhaps with an "if d" test of
the new request's existence), then remove the old request name, then
hand off to Peter, and then once he'd migrated _mom_(7) and handed off
back to me, I'd delete the scaffolding--killing off the alias or wrapper
macro.
For _actual_ examples of scaffolding use, I direct the reader to
_groff_'s commit log history.
[1] However, in theory, `length` might be broken enough that we'll
_have_ to replace it. Hmm, I can't find the ticket for this.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?67939>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
