Hi Junio, On Tue, 7 Jun 2022, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes: > > > On Fri, Jun 03 2022, Junio C Hamano wrote: > > > >> Indeed it makes it impossible to figure it out things like this case. > >> But ... > >> > >>> But this does look easy to "solve" with a quicker fix, just bringing > >>> back the "ci/print-test-failures.sh" step so you can at least expand > >>> it, and not have to go to the "summary" and download the *.zip of > >>> the log itself. I agree that re-adding the `ci/print-test-failures.sh` step makes sense, given the recent experience. > >>> As that shows we still have the raw log there, it just didn't make > >>> it to the new GitHub Markdown formatting mechanism. > >> > >> ... it seems a solution is possible? Care to send in a patch (or > >> perhaps Dscho already has a counter-proposal)? I will work on this. > > The only thing I have at the moment is: > > > > 1. git revert -m 1 bd37e9e41f5 > > 2. merge: https://lore.kernel.org/git/cover-v6-00.29-00000000000-20220525T094123Z-avarab@xxxxxxxxx/ > > 3. merge: https://lore.kernel.org/git/cover-v6-00.14-00000000000-20220525T100743Z-avarab@xxxxxxxxx/ > > > > I.e. to pick this in the sequence I'd proposed doing & have tested > > thoroughly. > > I know you two have difference in opinions, but throwing away everything > the other party did and forcing your stuff in is not a very effective > way to work together. I had already pointed out a rather terrible issue in that 29-strong patch series: Dropping Azure Pipelines support makes it unnecessarily harder to work on Git security issues. And it's not like we have an armada of people working on those. I, for one, am pretty worn out from the recent work. It might not be the intention of that patch series to make my life harder, but it sure would be its impact. And intent does not excuse impact. I therefore had to conclude that the patch series in this form cannot be merged. I recall that other reviews reached the same consensus, that this 29-strong patch series is too unfocused on any particular goal. So maybe calling this "my opinion" is not exactly fair. > > It also addresses other noted some other regressions in "next", but as > > noted e.g. in [A] there's other issues in "next", e.g. that even the > > "raw" trace logs are altered as a side-effect of running with > > --github-workflow-markup, and of course the major UX slowdowns. > > Dscho? I know you do not care about the UX slowdown as much as > others, but I am sure you do not consider what is in 'next' is > perfect. It seems to need further work to go back to the feature > parity with what it replaced. Indeed, I do not consider it perfect. I even said so much in every iteration's cover letter ;-) I will work on bringing back the `print-test-failures` step. Ciao, Dscho
