On Mon, Mar 07 2022, Johannes Schindelin wrote: > On Wed, 2 Mar 2022, Ævar Arnfjörð Bjarmason wrote: > >> >> On Tue, Mar 01 2022, Johannes Schindelin via GitGitGadget wrote: >> >> > Changes since v1: >> > >> > * In the patch that removed MAKE_TARGETS, a stale comment about that >> > variable is also removed. >> > * The comment about set -x has been adjusted because it no longer applies >> > as-is. >> > * The commit message of "ci: make it easier to find failed tests' logs in >> > the GitHub workflow" has been adjusted to motivate the improvement >> > better. >> >> Just briefly: Much of the feedback I had on v1 is still unanswered, > > Yes, because I got the sense that your feedback ignores the goal of making > it easier to diagnose test failures. I think that's a rather strange conclusion given that I've submitted a parallel series that makes some of those failures easier to diagnose than the same changes in this series. I.e. the failures in build v.s. test phases, not the individual test format output (but those are orthagonal). I think it's a fair summary of our differences that we're just placing different values on UX responsiveness. I'm pretty sure there's some amount of UX slowdown you'd consider unacceptable, no matter how much the output was improved. Clearly we just use it differently. >> or in the case of the performance issues I think just saying that this >> output is aimed at non-long-time-contributors doesn't really justify the >> large observed slowdowns. > > What good is a quickly-loading web site when it is less than useful? For all the flaws in the current output there are cases now where you can click on a failure, see a summary of the 1-2 tests that failed, and even find your way through the right place in the rather verbose raw log output in 1/4 or 1/2 the time it takes the initial page on the new UX to loda. > I'd much rather have a slow-loading web site that gets me to where I need > to be than a fast-loading one that leaves me as puzzled as before. I think it's clear that we're going to disagree on this point, but I'd still think that: * In a re-roll, you should amend these patches to clearly note that's a UX trade-off you're making, perhaps with rough before/after timings similar to the ones I've posted. I.e. now those patches say nothing about the UX change resulting in UX that's *much* slower than before. Clearly noting that trade-off for reviewers is not the same as saying the trade-off can't be made. * I don't see why the changes here can't be made configurable (and perhaps you'd argue they should be on by default) via the ci-config phase.
