* Richard Biener: > On Thu, Mar 19, 2020 at 2:28 PM Florian Weimer <f...@deneb.enyo.de> wrote: >> >> * Tom Tromey: >> >> > Also, gerrit was pretty bad about threading messages, so it became quite >> > hard to follow progress in email (but following all patches in the web >> > interface is very difficult, a problem shared by all these web UIs). >> >> What I found most disappointing was that the web interface doesn't >> guide you to the next reasonable step for your reviews and patches, >> like showing comments which need addressing. Tagging messages in an >> email client for later action actually works better than that, I think. > > I guess if anything we'd want something git-centric now like github > or gitlab pull requests & reviews. The only complication is approval > then which would still mean manual steps.
Gitlab has a “merge if CI passes” button, I think. There are similar third-party solutions for Github. > Patch review would also not be publicly visible and archived(?) so > both chiming in late after visible progress and archeology would be > harder. The comments could be archived on a mailing list. But there is only some threading. Maybe this can be compensated to some extent by producing smaller patches, so that there's less reason for mega-review-threads. I don't know if Gitlab supports patch reviews, or if you only can review all the squashed changes in a merge request. Github and Gerrit support comments on individual patches, but Pagure does not, so this is not something that has universal support in all such tools. (I would consider such a feature critical for glibc development.) I haven't figured out yet under what circumstances Github links commits to pull requests in the web UI. I'm not sure if this relationship is available outside the web UI. (Obviously, this is missing from the current gcc-patches feed as well.)