Re: [PATCH v2 0/9] ci: make Git's GitHub workflow output much more helpful

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

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.