Re: Gerrit status update

[Simon Marchi <simon.marchi@polymtl.ca>]

On 2019-12-05 7:14 p.m., Luis Machado wrote:
> On 11/22/19 6:58 PM, Simon Marchi wrote:
>> Hi all,
>>
>> We had a discussion on IRC yesterday about the shortcomings of Gerrit
>> for our workflow.  I'd like to share what was discussed, but also give
>> a chance to those who are not on IRC to have a voice.
> 
> Thanks.
> 
>>
>> The two main problems of Gerrit, when applied to our current workflow,
>> are related to patch series.  While it is possible to upload a sequence
>> of changes, it is not possible to treat a sequence of changes as a
>> logical patch series.  And therefore:
>>
>> - It is not possible to attach a cover letter to a series.
>> - The email notifications are not threaded like a series would.  It's
>>    basically impossible to follow a series by email, as each patch will
>>    have its own little thread.
>>
> I went through yours and Tom's e-mail, but also found glibc's take on it (https://sourceware.org/ml/libc-alpha/2019-11/msg00774.html).

Oh, thanks for pointing our that thread on the libc list, I didn't know about
it.  I also went through it, I think overall it summarizes the situation pretty
well.  You could s/glibc/gdb/ in the discussion and it would still apply.

> Carlos pointed out a possible way to have a cover letter, and apparently that is more or less the recommended way of doing it.

Yes, I agree that having an empty commit at the end of the chain would
probably work well enough.

> 
> It seems to me the biggest issue is having gerrit translated properly to e-mail format, both in terms of interaction and organization of replies (threaded series etc).
> 
> On the positive side i think gerrit provides quite a few useful features to speed up the process of submission and reviewing of patches, which people have already pointed out. So i won't list those here.

Agreed.

> Considering the drawbacks of gerrit seem to be mostly concentrated around series of patches, maybe bigger series in particular, should we try and do those through e-mail instead. Maybe as a recommendation?
> 
> For other smaller contributions, gerrit still seems to be fairly useful.

Hmm, I'm not sure I'd like to keep two parallel systems, with a vague rule
to tell which one to use.  It will be confusing for us and newcomers.

And don't forget that the initial goal of this effort is to improve the
tracking of patches, to avoid patches falling between the cracks.  If some
patches are sent by email and are not tracked, we are partially missing our
goal.

Also, I think the benefits of Gerrit shine particularly when dealing with
patch series, especially the diff-between-versions.  For a single patch,
I can easily apply the two patches locally and do a simple diff.

I just learned about git range-diff, reading the glibc thread.  I'll try to
use it in the future to compare patch series versions.  Although it doesn't
seem to be able to show the diffs using one's favorite diff viewer, and I'm
not particularly fond of reading raw diffs.

> As for patchwork, my experience using it in the past wasn't that great. It may have improved since then, but i remember it simply being forgotten over time, and patches piling up anyway.

Yes, that's what the experience has shown.  The amount of manual work required
to maintain it made it not worth it.  So I would not consider using Patchwork
without some accurate patch tracking based on some kind Change-Id, like we
have with Gerrit, that would allow us to do some automation.

We can start to do this outside Patchwork, using some script that use the
Patchwork API.  If that works well enough, we could even attempt to
contribute it upstream.  One of the Patchwork developer is open to include
this kind of feature:

  https://github.com/getpatchwork/patchwork/issues/327#issuecomment-561573729

Simon