On 2024-05-01 16:53, Tom Tromey via Overseers wrote:
> Mark> See also https://sourceware.org/bugzilla/show_bug.cgi?id=30997
> Mark> We really should automate this. There are several people running
> Mark> scripts by hand. The easiest would be to simply run it from a git
> Mark> hook. patchwork comes with a simple script that just calculates the
> Mark> hash and pings patchwork, which can then mark the patch associated
> Mark> with that hash as committed. If people really believe calculating a
> Mark> hash is too much work from a git hook then we can also simply run it
> Mark> from builder.sourceware.org. We already run a builder for each commit
> Mark> anyway. It would just be one extra build step checking the commit
> Mark> against patchwork.
>
> There's just no possibility this approach will work for gdb. It can't
> reliably recognize when a series is re-sent, or when patches land that
> are slightly different from what was submitted. Both of these are
> commonplace events in gdb.
>
> Tom
IMO, asking to always post the committed version as is (effectively
preventing doing "pushed with those nits fixed", or solving trivial
merge conflicts just before pushing) just to make patchwork happy would
be annoying and an additional burden, and noise on the mailing list.
The Change-Id trailer works very well for Gerrit: once you have the hook
installed you basically never have to think about it again, and Gerrit
is able to track patch versions perfectly accurately. A while ago, I
asked patchwork developers if they would be open to support something
like that to track patches, and they said they wouldn't be against it
(provided it's not mandatory) [1]. But somebody would have to implement
it.
Simon
[1] https://github.com/getpatchwork/patchwork/issues/327
