Re: Gerrit status update

[Tom Tromey <tom@tromey.com>]

Simon> I'd like to share what was discussed, but also give a chance to
Simon> those who are not on IRC to have a voice.

Thanks for doing this.

Simon> If we agree that we want to stop using Gerrit, I would disable the
Simon> creation of new changes, but still allow commenting and uploading new
Simon> change versions, so we can at least finish with the changes that are
Simon> there already.

If this happens, it would also be fine by me to just have everybody
resubmit their patches.


I switched most of my patch submissions to gerrit.  I find it has some
nice benefits -- the tracking, but also I think the review interface is
quite nice.  In some ways, it's even nicer than email, because I find
that side-by-side diffs are often easier to read.

However, I do find the lack of a cover letter and the lack of threading
to be minuses.  It's harder to follow gdb-patches now.


Simon> A newer version of Patchwork includes a git hook that can supposedly
Simon> automatically close patches when they are pushed to the git repository:
Simon>   https://patchwork.readthedocs.io/en/latest/deployment/installation/#optional-configure-your-vcs-to-automatically-update-patches
...
Simon> I am just a bit skeptical about how well (if it does it at all)
Simon> Patchwork handles patches or series versions.  If I send a v1 series
Simon> with 15 patches, then a v2 with 17 patches, including a few renamed
Simon> subjects, how does it cope with that?

I'm not too worried about this scenario (see below) but I think one to
test is if a patch is abandoned from the middle of a series.  Making
this work requires some notion of a series in the first place.  I think
the new Patchwork has this, but it's been a while since I looked.

Simon> Gerrit is able to track the multiple versions of a change because we
Simon> insert a unique Change-Id in the commit log of each patch.  This is very
Simon> reliable, and it would make handling of new versions/merged patches very
Simon> accurate.  But it goes against the Patchwork design:

Simon>   https://patchwork.readthedocs.io/en/latest/usage/design/

Simon>   "Don’t pollute the project’s changelogs with Patchwork poop

Simon>    A project’s changelogs are valuable - we don’t want to add Patchwork-specific metadata."

Simon> So unfortunately, we won't get that from upstream.  But it would always
Simon> be possible to modify Patchwork to add this feature for our own
Simon> enjoyment.

Yeah... I think this bit of Patchwork dogma is simply mistaken.
Reliability requires a patch ID that does not vary; and since git
doesn't provide this, it has to be provided externally.

Furthermore, we already accepted these IDs for gerrit.  I find them
readily ignorable.

I think modifying Patchwork to do this is very simple.  First, we could
either re-use the gerrit commit hook, or write our own (I wrote one
once, it's in my github).

Second, in the Patchwork tree is a file, tools/post-receive.hook.  This
is a shell script that has a function to get the patch hash:

    get_patchwork_hash() {
        local hash
        hash=$(git diff "$1~..$1" | python $PW_DIR/hasher.py)
        echo "$hash"
        test -n "$hash"
    }

I think all that's needed is to replace this with something to extract
our ID.  This can be done with "git interpret-trailers --parse".


One other thing gerrit provides is the ability to fetch patches from
gerrit.  This can be done with patchworks as well, using its CLI.
However, I imagine it is less reliable, since it isn't git on the other
end... like, with git you can do 3-way merges, but with patchworks you
couldn't.


I've looked at patchworks a little, as you can tell; but I haven't
looked at gerrit at all.  So, I have no idea of the relative difficulty
of adding the features we want to gerrit.

Tom