On Wed, Jun 08 2022, Johannes Schindelin wrote: > 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. You raised the same concern in February, and I made some practical suggestions for how to proceed with that in: https://lore.kernel.org/git/220222.86y2236ndp.gmgdl@xxxxxxxxxxxxxxxxxxx/ You didn't reply, and here was a reminder in late March: https://lore.kernel.org/git/cover-v2-00.25-00000000000-20220325T182534Z-avarab@xxxxxxxxx/ You then had a similar concern, and I replied again in early April saying I'd be happy to acomodate you, if you could reply to that original E-Mail and clarify what you'd like exactly: https://lore.kernel.org/git/220406.86bkxeecoi.gmgdl@xxxxxxxxxxxxxxxxxxx/ And here's a mention of it again in late April: https://lore.kernel.org/git/220421.86fsm66zmz.gmgdl@xxxxxxxxxxxxxxxxxxx/ Then a few weeks ago you brought up the same point, and I replied again you to please reply to that E-mail from back in February: https://lore.kernel.org/git/220524.86y1yrwaw0.gmgdl@xxxxxxxxxxxxxxxxxxx/ So really Johannes, I'm completely fine with accommodating you. But when you suggest that some ad-hoc combination of out-of-tree code and not-used-in-tree code you have must not be touched *and* you're seemingly unwilling to figure out some way forward you're not being very helpful. Instead you just keep repeating that something must not be changed, and when it's pointed out to you that that would block someone else's patches, but would you be OK with X, Y or Z you seemingly just blackhole the replies you get. So can you reply to that this time? Thanks. > 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. Yes, that's something others brought up, but it's unrelated to the Azure issue you're raising here. That change was contained within the first 6 or so patches of that series.
