On Wed, Apr 20 2022, Junio C Hamano wrote: > Phillip Wood <phillip.wood123@xxxxxxxxx> writes: > >> ... There is a complication though in that Dscho's series >> adds github markup to the build output and this series separates the >> build from the tests which means that is not necessary. I think it >> should be easy enough to change Dscho's series so it only uses github >> markup for the tests which is the main improvement and just wait for >> the build and tests to be separated in this series (ideally they'd be >> a short easy to review series that did just that). > > OK, Dscho, Ævar, does that sound like a workable plan? See a reroll > of Dscho's series (which Phillip considers "should be easy enough") > first, get it solid enough and merge down to 'next', and then see > the refactoring by Ævar on top, hopefully with a minumum churn that > makes it impossible for people to review? First. I see you re-queued a the v2 of Johannes's patches. I had some outstanding fixes for my series [2] + the derived version of his on top [3] which I thought I'd submit regardless. To reply a bit to the thread at large, quoting Phillip: On Wed, Apr 20 2022, Phillip Wood wrote: > It would certainly be nice to get Dscho's updates merged sooner rather > than later as I think they represent a more significant improvement > for CI users. There is a complication though in that Dscho's series > adds github markup to the build output and this series separates the > build from the tests which means that is not necessary. I think it > should be easy enough to change Dscho's series so it only uses github > markup for the tests which is the main improvement and just wait for > the build and tests to be separated in this series (ideally they'd be > a short easy to review series that did just that). Phillip: I'd be very happy to see a version of my [2] rebased on [2] (or [3]), rather than the other way around. I'm fairly sure that if you attempt to do so you won't find it to be all that easy. If you do and come up with some version which Johannes is OK with I'd be very happy with it. Without that I don't see how I wouldn't be in the same rut of wanting to improve other parts of the CI and that being brought up as a perceived blocker, without a suggested way forward (per [4]). But as to a way forward. Even though my series is larger I still think a much better way forward is to do it first. There's been some bugs here & there (all of which I believe are resolved), but I don't think anyone's spotted anything that's fundamentally wrong with that needs to be addressed in some open-ended way. Whereas Johannes's v2 changes some UX things arguably for the better, but also introduces severe performance regressions in the UX. See [5] and [6]. I was routinely seeing e.g. ~5s loading times go to ~20s. Now, I'm not sure (I haven't re-done the measurements), but I have a hunch that basing it on top of my series made it much better. That's because in Johannes's the GitHub folding JS needs to fold the equivalent of make+make test+his GitHub markup. If it's based my series the the "make" steps are in their own "step", which it looks as though the GitHub UX needs to do less work to fold/unfold. 1. https://lore.kernel.org/git/pull.1117.v2.git.1646130289.gitgitgadget@xxxxxxxxx/ 2. https://lore.kernel.org/git/cover-v5-00.29-00000000000-20220421T181526Z-avarab@xxxxxxxxx/ 3. https://lore.kernel.org/git/RFC-cover-v5-00.10-00000000000-20220421T183001Z-avarab@xxxxxxxxx/ 4. https://lore.kernel.org/git/220421.86fsm66zmz.gmgdl@xxxxxxxxxxxxxxxxxxx/ 5. https://lore.kernel.org/git/220220.86bkz1d7hm.gmgdl@xxxxxxxxxxxxxxxxxxx/ 6. https://lore.kernel.org/git/220222.86tucr6kz5.gmgdl@xxxxxxxxxxxxxxxxxxx/
