Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes: > 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). If you have a counter-proposal that you feel is solid enough, I do not mind dropping the topic in question and replacing it with the counter-proposal to let people see how it fares for a few days. If it allows others to view the output easily if you revert the merge of this topic into 'seen' and replace with the counter-proposal and push it to your own repository, that would be an even better way to highlight the differences of two approaches, as that would allow us to see the same failures side-by-side. Am I correct to understand that one of the the common goals here is to eliminate the need to discover how to get to the first failure output without turning it slow by 10x to load the output? > 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. Whether we perform counter-proposal comparison or not, the above is a reasonable thing to ask. > * 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. I do not know if such a knob is feasible, though. Thanks.
