* 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.)

Reply via email to