Hi Deri, At 2026-02-23T13:31:52+0000, Deri wrote: > On Sunday, 22 February 2026 20:59:36 GMT G. Branden Robinson wrote: > > At 2026-02-22T19:13:54+0000, Deri wrote: > > > On Sunday, 22 February 2026 07:18:59 GMT G. Branden Robinson > > > wrote: > > > > At 2026-02-21T13:50:16+0000, Deri wrote: > > > > > This is a strange one!! The error occurs if you don't have the > > > > > file doc/ gnu.eps (because PSPIC can't find it). doc.am makes > > > > > it (from doc/gnu.xpm) but in "out-of-tree" builds it ends up > > > > > in build/doc/gnu.eps, and not found. > > > > > > > > > > The regression was introduced by commit e9da162af80 (Feb 7, > > > > > 2026), reverting fixes it. > > > > > > > > I should point out that this is an incorrect, or at best > > > > incomplete, analysis. > > > > > > I'm interested to know which bits of the analysis was incorrect. > > > > I did also say "or at best incomplete", which I maintain it was, but > > I guess you're contesting that, too. Or maybe not--see below. > > > > > Given the starting point was:- > > > > > > GROFF doc/webpage.html > > > > > > pre-grohtml: fatal error: 'pre-grohtml' exited with status 4; > > > re-run with a different output driver to see diagnostic messages > > > > > > And your initial analysis was to look at pre-grohtml and decide it > > > could not happen. > > > > When a program fails with a fatal error, why would it not make sense > > to look first at the complaining program? > > [...] > > > > > So was my analysis that PSPIC was causing the error incorrect? > > > > It seems so. Your proposed reversion changed nothing in > > "tmac/pspic.tmac", and the fix I think to be better[1] doesn't > > either. > > i did not propose a reversion, i pointed you to the commit which > caused the error to be manifested.
Here's what you said: >>>>> The regression was introduced by commit e9da162af80 (Feb 7, 2026), >>>>> reverting fixes it. https://lists.gnu.org/archive/html/groff/2026-02/msg00087.html I disagree both that commit e9da162af80 constituted a regression (in this respect; it's possible it caused some other problem not discussed in this thread), and that reverting it "fixes" the problem. I reiterate: what commit e9da162af80 did was expose a latent bug. Reverting that commit, and dropping the reversion, respectively re-conceal and re-expose the latent bug--which is not necessarily the same thing as a fix. (It seems that, later, we managed to reach agreement on this point.) > if webpage.ms did not use pspic no error would occur - so the > statement is patently correct. Well, okay. If the build didn't use _groff_ to generate "webpage.html" from "webpage.ms", no error would occur, either. So I'd characterize your "patent correctness" as a "vacuous truth". https://en.wikipedia.org/wiki/Vacuous_truth > We both know language is imprecvise, prtic ulry enghl;ish. It is also > a martk of intell;igence, thhe ability to derivbe meaning while > ignopring noise in the signal, by using context as well as the signal. > since you are imtellighent i have decidfed not to correct keyboard > mistakes due to hand tremors. Suit yourself. I suggest that a "meeting of the minds" requires a "discursive process", meaning that effort to arrive at a common lexicon is made by all parties. > > > Was doc.am building gnu.eps in the destdir - is this not true? > > > > Here's another terminological problem. > > given i had berwen talking asbout doc/ and build/doc in the orighinal > analysis its more likely an intelligenty persdon would assume i wasd > talking about $9odoc-srcdirP) and $(doc-builddir0. Its a bit of an > athletic stretychb to assumne ity was meant to refer to the install > directory. Stick a pin in this observation--I'll return to it. > > Literally, no. doc.am (or make(1)) doesn't "build gnu.eps in the > > destdir". `DESTDIR`, in a widely adopted Makefile convention that > > Automake also employs,[2] refers to _the directory to which files > > are installed_. Your term, "destdir", is either undefined or > > irrelevant to what happens when you run a groff "make" with its > > default target (or ask for "doc/webpage.html" specifically), because > > neither of those involve performing _installation_. > > and yet you manager itg. With additional effort, sure. I don't think it's helpful to anyone reading to be careless with terminology referring to concepts that have a demonstrable track record, which I've already pointed out, of causing confusion and build failures. Perhaps you disagree. > > We've had much grief over the years with the "doc.am" file arising > > from confusion of (1) the source tree, (2) the build tree, and (3) > > the installation directory (`DESTDIR`), which can all be distinct. > > And, if we follow the path of glibc and binutils as recently pointed > > out by Collin Funk, will become distinct for _all_ supported build > > scenarios. > > ihopde so. Add a second pin to the first. > > > Was grohtml being instructed to look in the srcdir - where it > > > should not exist in an out-of-tree build - but obviously did when > > > you were testing. > > > > If by this you mean "was `-I $(doc_srcdir)` being passed to `groff > > -Thtml`", then yes, but that's an invariant. It was true in 2014, > > was true before my commit on 7 February, was true after, and is > > still true in my working copy, which has the fix I believe to be > > "correct".[1] > > so this was not incorrect. There exists an uncountable number of correct statements that are irrelevant to diagnosis and remedy of any particular bug. However, I'll concede that this one is only _mostly_, not _totally_, irrelevant, as I'll show in a moment. > correct but...? i'm dubious. the logical fix would be tyo just replace > srcdir with builddir, since there is no need to have both. For in-tree > they woiuijld be the same. i don't believe there is anything in the > srcdir that groff needs to include. Time to pull the pins out. I invite you to go ahead and apply that logical fix to your working copy, ignoring mine. Then (configure however you usually do and) "make dist". I predict that you will observe a build failure. I'll take a leaf from your book and offer no more than this "steering". > > > Was it working before Feb 7th commit, or is that incorrect. > > > > Yes. And it was also working _after_ 7 February, for me and for > > several of Bruno Haible's builds. Bjarni's the only person who > > reported a problem, and unfortunately he has a track record of > > reporting against GNU groff problems that affect only his private > > fork of it.[3] > > Another correct statyerment then. You were told it only affected out > of tree builds on git, No; you've misplaced a modifier. We were told _only_ that it affected a build "after cloning groff". Bjarni didn't actually say which target he attempted to make. Review <https://lists.gnu.org/archive/html/groff/2026-02/msg00081.html>. I did _guess_ that Bjarni _wasn't_ referring to a build from a distribution archive (which, after a "regular" build, is what "make dist" does), and so, it seems, did you. But that was inference. We were not "told". > not dist tars. So Bruno would not see it. It workesd for you because > your source tree was polluted - as i diagnosed. Take as many victory laps as you like, then. You found pollution in my working copy. > > > I do not comment on whether my analysis is incomplete, it was > > > obviously sufficient to steer you onto the right track to fix the > > > problem > > > > If I still had driving to do after having been "steered", then you > > are conceding that it was incomplete. > > The only driving required was to prepare a commit whicjh fixed the > problem i jhad diagnosed for you, and even that causes questions of > why you did it that way. mayde its something about drivinmg on the > wrong side of the road. Please, be my guest and drive on your correct side, substituting "$(doc_builddir)" for "$(doc_srcdir)". Then configure and run "make dist". [snip] > > I found this confusing (and still do). "but troff's -I looks in > > $(doc_srcdir)" is, as I noted above, an invariant across the entire > > history of the "doc.am" file, even with respect to a commit I haven't > > pushed yet. > > The history of doc.am has no bearing on what is needed now to maker > it work properly now. I disagree. As the relevant commit in my working copy puts it: "My commit c81db845da, 2022-04-06 introduced a latent bug that my commit e9da162af8, 2026-02-07 exposed." Also see footnote 5 in <https://lists.gnu.org/archive/html/groff/2026-02/msg00121.html>. > > So saying that a thing I _don't_ need to change is "exactly the > > problem" when I need to be changing some _other_ thing--even a > > lexically adjacent thing--was not, at the time, illuminating to me. > > dignal noise inyelligence. Have you tried out your correct-side-of-the-road fix on the "make dist" test track yet? > > > I know I'm just a quadriplegic spastic so can't possibly operate > > > in the higher realms of intellectual thought, but give me a little > > > credit if I strike it lucky. (Or is it luck). :-) > > > > I think neglecting to precisely use language where doing so is > > necessary to reach mutual understanding accounts for a much greater > > proportion of our failures of communication than random variables or > > CNS differences. > > If you always start from tyhe premise that you are alwaya right, and > only communication using your version of "precise language" has a > chance of changing your mind, it makes it very difficult for the rest > of us. I think attempts at mind-reading, like the foregoing, present comparable difficulties in a discussion forum. If you persist in replacing the words people actually express to you with your wholesale rewrites thereof, they are likely to tire of speaking with you. > Personally I start with the premise the other person probably has a > valid point, even if, at first read, what they are saying appears > wrong, I then synthesize in what circumstance their point would make > sense. I think I do this too, but I stop at a point much earlier in the process you do. When I lack information necessary to resolve a problem, I say so, as I did to Bjarni, from which you concluded that I asserted his problem was nonexistent. That I neither said nor implied. I said only that I did not (at the time) regard his problem report as gating the groff 1.24.0 release. Your translation of that statement to "this is not a problem" makes communication, shall we say, "very difficult". > This is how I got from your "Can't reproduce" to you must have a copy > of gnu.eps in your source tree, since then your continued denial of a > problem made sense. Identifying a problem as "unreproducible" is not "denying" it. See, for example, <https://savannah.gnu.org/bugs/?68064>, which was for a time marked as "Unreproducible" without drawing rancor from the submitter. That ticket could _still_ be classified that way, because Dave and I are having trouble getting results totally consistent with the submitter's and with each other. The ticket remains open because the consensus is that something fishy is going on, but we're not sure what, and it doesn't seem to affect the current RC. _And_ it's not a gate for the groff 1.24.0 release. But no one has gotten upset or ventured recriminations. Perhaps if you'd been involved in that discussion, your impressive powers of mind-reading could have increased the temperature and protracted the exchange as you've done here. > > > > And the problem that _should_ have been revealed was masked on > > > > my system because of the lingering (and all but hidden by > > > > ".gitignore") "doc/gnu.eps" file in my _source_ directory, which > > > > was (roughly) your analysis. But that was only one piece of the > > > > puzzle. > > > > > > Part of it, but only in so far as explaining why you kept claiming > > > it was not a problem. > > > > "Kept claiming". First, you invented me saying "there wasn't a > > problem" once. Now, it's multiple times. Okay, I just identified > > an additional first-order factor contributing to our failures of > > communication. Try sticking to the words I actually write. > > Here we go:- > > "I don't regard your report as gating the groff 1.24.0 release." <i.e. > no prob - since normally a build failure would gate> No. Massively overstated. Normally a build failure would not gate. It's _easy_ to get a groff build to fail. Run out of disk space. Remove build dependencies, or don't have them installed in the first place. Make local changes to your working copy. As an experienced groff developer, you've grown accustomed to your own routines and practices when performing a build, and I infer that you have well disciplined practices in this area. When a build fails for _you_--I'm guessing here--it more likely than not indicates a defect. That is not a claim that can be made in the general case, and not in Bjarni's, who frequently builds his fork of groff rather than GNU's, and has to cope with defects of his own making that no one else can see. A report of a build failure gates a release only if (1) it arose from a known state of the source and build trees--the best example being an unpacked distribution archive like groff-1.24.0.rc4.tar.gz--and either (2) the cause is understood, and known to be of wide impact; or (3) we have multiple reports of the same failure. Criterion 3 makes host-local problems like those enumerated above in my "massively overstated" paragraph _much_ less likely, as people and their systems are diverse; any two are unlikely to be perturbed in exactly the same way from normative conditions for building. > "Well then it's _extra_ strange, because I _can't_ reproduce it. (And > didn't on 7 February, because I would not have pushed if I'd been able > to see this defect, which I certainly should have because I do an out > of tree build 3-4 times[1] immediately before pushing.)" <i.e. no prob > - the report is false> "Unreproducible" is not a synonym for "false". Please take a moment to review a précis of the scientific method. > "Can't reproduce." <i.e. no problem> No. "Can't reproduce" implies "not resolvable at this time". We have plenty of open tickets in Savannah describing defects where a solution is not yet known, or not even known to have their origins in groff itself. The aforementioned Savannah #68064 is an example. > "For me, this is working as planned and intended." <i.e. no prob> Do you think it is common in software development to undertake changes when one can't tell whether a defect has been resolved or not? Actually, it's _too_ common. But they're the scenarios that software engineers (and their managers) dread, because if a defect can't be reproduced at the site where the engineers assigned to it work, they either leave the defect unresolved or have to drive/fly out to a site where it can, and troubleshoot the problem in the field. Few people enjoy that process, especially those who have to pay for it. See, for example, Dennis Ritchie's "A Hardware Story". https://www.nokia.com/bell-labs/about/dennis-m-ritchie/odd.html > "> If you are not seeing the error please check you have not got a > rogue doc/ gnu.eps in the source doc/ directory. > > I don't. See my "find" command above." <i.e. Deri's wrong - there is > no problem here> If "find" can't locate a file on my file system, what alternative means of locating it do you propose? That I can use without consulting you as an infallible oracle, I mean. > "Deri's hypothesis did not bear out for me. I didn't need "gnu.eps" > in my build tree for "webpage.html" to be successfully generated." > <i.e. Deri's wrong - there is no problem here> Have you tried a lap around the test track with your more correct fix and "make dist" yet? > "> Which actually proves I am correct, you do have a "rogue" copy in > the > > source directory. Possibly left over from an in-tree build, another > > good reason for dropping in-tree builds. > > This much is true. "doc/gnu.eps" is not tracked in git:" <finally, > there is aproblem - which is causing me not to see the reported build > problem> While I did not change my mind that there wasn't a problem--because I never made that claim in the first place, despite your repeated efforts to shove it into my mouth as an irritated parent would to a weaning infant--I did change my mind that the report wasn't actionable, because, at your prompting, I made changes to my host environment that rendered me able to reproduce the problem. As the economist Paul Samuelson said: "Different editions of my textbook have been quoted. In the first edition I said a five percent rate [of inflation] is tolerable. Then I worked it down to three percent and then down to two percent and the AP carried a wire “Author Should Make Up His Mind.” Well when events change, I change my mind. What do you do?" > All from:- > > https://lists.gnu.org/archive/html/groff/2026-02/msg00085.html > https://lists.gnu.org/archive/html/groff/2026-02/msg00088.html > https://lists.gnu.org/archive/html/groff/2026-02/msg00093.html > https://lists.gnu.org/archive/html/groff/2026-02/msg00105.html > > In terms of denying there was a problem, you don't have to say the > actual words, justr demonstrate you believe no problem uxists. Evidently, I'll never have to say anything is not a problem ever again-- I can rely on you to proclaim that I've said it under any circumstances that suit you. > > > The real analysis was that PSPIC was the culprit, > > > > Completely disagree. What about the file "tmac/pspic.tmac", which > > defines the `PSPIC` macro, would you change to resolve the defect > > Bjarni reported? Alternatively, what would change in "webpage.ms", > > which contains the `PSPIC` macro call that ultimately failed? > > remove .pspic from webpage.ms and the error goes. so if you want to > knoiw what caused the exit 4 you can say the presence of pspic in > webpage.ms. We could just as well say 'the presence of -Thtml" in the corresponding target rule in "doc/doc.am"'; while wrong, it would at least identify the correct file to change. > > The culprit was a long-standing latent bug involving insufficient > > preparation of a groff(1) command line in a Makefile.[5] > > Yes i pointyed you to doc.am. ...so why harp on "pspic"? > > > and even pointed you at the commit to examine so that you could > > > look at the changes which caused the issue. > > > > Not _caused_ the issue. _Exposed the latent issue_. > > lets be a bit more accurate here, the latent issue was exposed I'm glad we can agree on that much, at last. > through making chabges without fully understanding What constitutes "full understanding" in your view? Have you always possessed "full understanding" of gropdf? You've never had to fix a bug in it that you introduced yourself, then? > why the previous code was working, and adding the new code caused it > to no longer work. I don't even understand how this phrasing semantically differs from my own. Any time one is surprised by exposure of a latent--meaning previously hidden--bug, that's clear evidence that, despite appearances, one didn't "fully understand why the previous code was working". Thus my statement: > > Not _caused_ the issue. _Exposed the latent issue_. You've mired yourself so deeply in a contrarian muck that you can't even feel yourself satisfied by a concession of error on my part. If you're frustrated by being stuck there, you have the means to free yourself. > > > The analysis you added was just why the previous version worked, I > > > did not think that was necessary to fix the problem. > > > > I'm not excited to play the "experienced software engineer" card on > > you, but it _frequently_ happens in the field that when a bug has > > undergone a root-cause analysis, its longevity (or persistence) is > > discovered to be much greater than is consistent with the timing of > > report(s) that led to its investigation. People wind up saying > > things like... > > > > "Wait a minute--how did this _ever_ work?" > > But we know it did work, soi the analysis is faultty if you can't > answer the question. Again, you're finding a strange way to disagree with me--by agreeing with my premises _and_ conclusion. That a latent bug is exposed doesn't mean nothing needs to change--it necessarily means the opposite! But speaking of faulty analyses, please apply your more correct fix to your working copy and "make dist". > > > The text in troff.1 is a little misleading since it assigns the -I > > > directory search for the \X'ps: import ...' to troff, but troff > > > does nothing with this, it is the fact -I is passed to grops which > > > allows the import to happen. This is different from psbb, so and > > > soquiet, but occurs in the same sentence. > > > > That's a reasonable point. Want to pitch a recast? :) > > This is a joke;- > > ‘-Idir’ > This option may be used to specify a directory to search for files. It is > passed to the following programs: > • gsoelim (see gsoelim for more details); it also implies groff’s -s option. > • gtroff; it is used to search files named in the psbb and so requests. > • grops; it is used to search files named in the ‘\X’ps: import’ and > ‘\X’ps: file’ escapes. > The current directory is always searched first. This option may be specified > more than once; the directories are searched in the order specified. No direc- > tory search is performed for files specified using an absolute path. > > (groff.pdf circa 1.22.4) So...your joke is that I should revert groff's Texinfo manual to its state at the 1.22.4 tag? Huh. Well, you're consistent, at least. In this respect. :) > > > First, I never suggested you should revert, just that reverting > > > fixed the problem, > > > > I wouldn't say that much, especially now that the root cause is > > known. > > > > Reverting the change _re-concealed a latent problem_. > > > > It's always good to have some small thing one can toggle to make a > > bug manifest and then go away again, but that doesn't mean the thing > > you're toggling _is_ the problem. > > Exactly, I identified the toggle for you, not suggesting revert was > needed. Except by suggesting that reverting the commit was sufficient to resolve the problem. >>>>> The regression was introduced by commit e9da162af80 (Feb 7, 2026), >>>>> reverting fixes it. https://lists.gnu.org/archive/html/groff/2026-02/msg00087.html You did offer an alternative "fix" in the same message: >>> Now fix it. >>> >>> [derij@pip build (master)]$ cp doc/gnu.eps ../doc But as this constitutes a modification to the _source_ tree, after a build has (partially) been performed, it's inapplicable to the Git repository. That is, it's not a fix groff developers can deliver to users. A "fix" that is a diagnostic tool, but not a remedy, is not a fix. A "fix" that we can't apply to the groff Git repository is not a fix. > > A sketch of next steps from there is: > > > > 1. reduce the size of the toggled change to the minimum syntactical > > alternation that changes the behavior; and > > 2. understand why that change alters the behavior. > > > > If the toggling change alters observable behavior _but shouldn't_, > > you know that you haven't yet found the root cause of the problem. > > i believe this is the minimum change which removes the problem. > > diff --git a/doc/doc.am b/doc/doc.am > index d5a0c9eaf..191f5289e 100644 > --- a/doc/doc.am > +++ b/doc/doc.am > @@ -416,7 +416,7 @@ doc/webpage.html: $(DOC_GNU_EPS) tmac/www.tmac tbl > doc/webpage.html: $(doc_srcdir)/groff.css > doc/webpage.html: $(doc_srcdir)/webpage.ms $(TMAC_PACKAGE_MS) > $(GROFF_V)$(MKDIR_P) $(doc_builddir) \ > - && $(DOC_GROFF) -t -I $(doc_srcdir) -P-jdoc/webpage -P-nrb \ > + && $(DOC_GROFF) -t -I $(doc_builddir) -P-jdoc/webpage -P-nrb \ > -P-Iwebpage -P-Ddoc/img -Thtml -ms $(doc_srcdir)/webpage.ms \ > > [email protected] \ > && mv [email protected] $@ As I've said several times in this message, please try it. With "make dist". > A regression does not always require a revert, duh! I agree! You might illustrate your command of this blatantly obvious ("duh!") fact by prescribing reversions _as fixes_ less frequently and less aggressively, and with a focus on their utility as diagnostic tools rather than remedies. Why do I say "as fixes"? Because... >>>>> The regression was introduced by commit e9da162af80 (Feb 7, 2026), >>>>> reverting fixes it. ...of statements like that. I grant that you can rebut me with the observation that you sometimes mean one thing by "fixes" and sometimes another. I think equivocation is hazardous. > it requires the mistake which caused the regression to be fixed. If the regression is thought to actually be a problem (that is, there was a mistake in the first place), and a "serious enough" one at that, yes. We can observe in mandoc(1)'s CVS history several cases where I "regressed" groff under Ingo's definition of "regression" (and I guess yours), but he decided to adapt mandoc to groff's change, because he thought the new behavior to be better. See, for example, revisions 1.248, 1.245, 1.244, and 1.240 in mandoc's "man_term.c" files. https://cvsweb.bsd.lv/mandoc/man_term.c > Very good, your synthesizing what may have caused the problem. Condescension is a rug that really ties the room together. > However I'll give you two facts:- > > After a make clean or make distclean:- > > [derij@pip build (master)]$ l doc > gnu.eps groff.dvi.t2d/ groff.html.node/ groff.info-1 groff.info-3 > groff.pdf.t2p/ groff.txt > groff.dvi groff.html groff.info groff.info-2 groff.pdf > groff.texi img/ > > notice gnu.eps (among a surprising number of other files) is still > present. I acknowledge your surprise. Here are some resources. https://www.gnu.org/software/automake/manual/html_node/Clean.html https://www.gnu.org/software/automake/manual/html_node/Basics-of-Distribution.html https://cgit.git.savannah.gnu.org/cgit/groff.git/tree/doc/doc.am?h=1.24.0.rc4#n773 > Doing an in-tree build will put gnu.eps into your source doc directory Yes. > and I bet a make clean does not touch it. Correct. And the "distclean" target _won't_ clean it. On purpose. See links above. > meaning it will live there until manually removed. Manual removal is not (usually) necessary. https://cgit.git.savannah.gnu.org/cgit/groff.git/tree/doc/doc.am?h=1.24.0.rc4#n674 (An exception is when one pivots from an in-tree to out-of-tree build without doing "make maintainer-clean" first.) > > > and that makes it a regression in my universe. > > > > That definition is unsatisfactory to me. Did _the build_ regress in > > some way? Yes. Was _that commit_ of itself a regression? No. Did > > that commit expose a latent bug? Yes. Did that bug warrant > > investigation upon being reproduced by others? HELL yes. > > This is why I don't link reversion to regression. You _did_ link them. >>>>> The regression was introduced by commit e9da162af80 (Feb 7, 2026), >>>>> reverting fixes it. So do I, but only sometimes. Reversion is one tool for diagnosing regression. > a regression can be fiuxzeed by a further commuit, as in this case. > occasionally a regression may require a complete reversion but only > when the intention behind a particular change is proved to be bonkers. I'm pleased to say I completely agree. > > By affixing the term "regression" to a commit that _doesn't > > constitute the introduction of a defect_, we distract our attention > > from the necessary work of locating where a defect truly is. That > > distraction in turn neglects to exercise our ability to recognize > > defects. > > It is perfectly fair to label a commit as a regression, iuf that is > the poinmnt from which regressed behaviouris obdservedf. But here, again, I disagree. By that logic we can say that I've added regressions to the groff build tree on the order of 300 times--namely, each time I committed a regression test script annotated: >> Test fails at this commit. Because, as the annotation implies, "make check" is expected to fail. And a defect in the test script would be implied if, in fact, "make check" _didn't_ fail. (...if the test weren't skipped, in which case the committer needs to arrange for conditions where the test will be exercised before committing the its script, lest it produce false negatives--meaning, fail to report incorrect behavior.) But is that characterization _useful_? Does it draw our attention to problems that need to be resolved or improvements that could be made? Or is it, as I termed it earlier, a wisdom-abusing distraction? Such distractions are what give rise to adages like "the map is not the territory" and observations like Goodhart's Law. I suggest that a robotic application of the term "regression" does not serve us well in pursuing effective software development. https://en.wikipedia.org/wiki/Goodhart%27s_law I further predict that time-consuming threads like this one are inevitable when we fail to dispel points of confusion like that. > it may not be the cause of the defect but it bis empirically the point > from when the regression is observed. I would say simply, for example, "as of commit e9da162af80, a repo build fails for me". If that is all one has observed, one cannot yet rightly say that a code regression has occurred. More information is required. Consider a scenario where we add a build dependency, somebody has a working copy, doesn't review the commit log since their last pull, and fires off a build--which then fails because "make" tried to run a command or read a file that was not found, or (preferably) our "configure" script went looking for the required resource, didn't find it, and deliberately aborted. Such a person should not rush to this mailing list screaming of a code regression. But, under your proffered definitions, they are justified in doing precisely that. Because, empirically, the build regressed for them, and reverting one (or more) of the commit(s) that introduced the dependency would fix it. You did not comment on my advice to read David Agans's book on debugging, but here's a summary by David A. Wheeler that fairly characterizes (and summarizes) it. https://dwheeler.com/essays/debugging-agans.html Regards, Branden
signature.asc
Description: PGP signature
