> -----Original Message----- > From: Gcc <gcc-boun...@gcc.gnu.org> On Behalf Of Florian Weimer > Sent: Thursday, March 19, 2020 1:59 PM > To: Richard Biener <richard.guent...@gmail.com> > Cc: overse...@gcc.gnu.org; Jonathan Wakely via Gcc <gcc@gcc.gnu.org>; > Overseers mailing list <overse...@sourceware.org>; Segher Boessenkool > <seg...@kernel.crashing.org>; Alexander Monakov <amona...@ispras.ru>; > Frank Ch. Eigler <f...@elastic.org>; Frank Ch. Eigler <f...@redhat.com>; > Tom Tromey <t...@tromey.com> > Subject: Re: Not usable email content encoding > > * 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.
A bit late to the party, but this really doesn't work that well because until recent version of gitlab there was no fairness guarantee. another patch could be approved after mine (with hours in between because of CI) and yet still get merged first causing my own patch to no longer apply, you'd rebase and roll the dice again. To fix this they added merge trains https://docs.gitlab.com/ee/ci/merge_request_pipelines/pipelines_for_merged_results/merge_trains/ but trains for GCC Will likely be very short because of Changelog conflicts. So I don't think an automated merge workflow would work for projects where every single commit changes the same files. For these workflows to work as well you'd need to have a policy that every single commit go through CI, as a non-green master could flush your entire train if it's rebased on a bad commit. > > > 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.)
