Re: Setup non-pushing gerrit instance for glibc.

[Sergio Durigan Junior <sergiodj at redhat dot com>]

On Friday, October 25 2019, Joseph Myers wrote:

> On Fri, 25 Oct 2019, Sergio Durigan Junior wrote:
>
>> footer needs to be preserved when replying to it.  We will also have to
>> warn the user that replying directly to a new change message will not
>> work; gerrit can only understand email replies to comments.
>
> That seems like an even more serious issue for usability of email replies, 
> in that a reply to a new patch submission could well be the most common 
> case.

I understand (and share) the frustration (really do!), but I think we
should take a step back and consider what the community wants, and what
gerrit offers.

Gerrit will probably never be able to be fully functional with email,
because that is not how it is designed.  We can and will file bugs and
RFEs against the upstream project, but, as far as I understand it, it
just is not designed to be 100% compatible with mailing list-based
reviews.  Its main goal is to provide a web-based patch reviewing
system, and this is how its developers expect people to use it.

If you look at other projects that use gerrit, you will notice that, for
most of them, their entire flow of communication happens in the web
interface.  They can even have a mailing list which receives email
notifications from gerrit, but their use of email is pretty basic (i.e.,
a lot of times their gerrit instance doesn't attach the patches to the
emails, nor allows email replies).  It's only a way of letting other
people know: "Hey, there's a new change to be reviewed, please go to
this URL and check it out".

When the GDB community decided to give gerrit a try, the main problem it
was looking to solve was the "patches go missing" issue.  Basically, we
have a lot of patches being sent to the project and not so many
reviewers, so it's not uncommon for a patch to get "buried" waiting for
a review, and if the author doesn't ping it, it gets lost.  With gerrit,
you can get a pretty good view of all the patches that were submitted so
far, and you can always check if a patch is too old or if it's been too
long since the last interaction on it.

What the GDB (and now the glibc) community is now having to decide is
whether it is beneficial to abandon our mailing list-based workflow
(with all its pros and cons) and start using a web-based workflow (with
all its pros and cons).  Simon and I are doing our best to accomodate
the needs of those who would like to stay in the email camp as much as
we can, but it just won't be possible to say "you can use only email if
you want, no need to go to the web interface".

There are of course other tools that we can consider.  For example,
recently we started looking into re-activating the patchwork
installation on sourceware.org, upgrading it, and implementing hooks
which will make it possible for the patchwork software to automatically
"close"/"archive" patches which have been pushed to the repo.  If we
choose to go this route, we will still be able to use emails to review
patches, but we will lose the features gerrit offers.

Anyway, I'm sorry about writing so much, but I wanted to give you folks
a broader perspective of why we're trying gerrit, and what we can
reasonably expect from it.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/