Re: New list for people to share maintainer workflows

[Paolo Bonzini <pbonzini@redhat.com>]

On 14/09/19 18:45, Drew DeVault wrote:
> # Identifying different versions of the same patchset.
> 
> Like you mentioned, no one likes Change Ids, including me. So far the
> best option I've considered is checking the date - it gets perserved
> even through rebases and is /basically/ unique. Enough rebasing and it
> *will* get lost, though, and then manual intervention is required.
> 
> I've considered a few ways to address this. One route might be to make
> git send-email smarter, and utilize heuristics on the reflog to try and
> identify that a patch is a -v2. Then we can add an email header like
> `Superceeds: <commit or message id or something new>`.

The date however is lost across git-send-email.  However, you can match
series, rather than patches; a Superseeds header would be nice for that,
but often times it is enough to match on the subject to get a decent result.

It's then possible to run a minimal matching algorithm to identify a
patch that "moves" across revisions of the series.  This is how "git
range-diff" works.

By the way, let me introduce Patchew! [1] Patchew was started when
patchwork seemed to be mostly dead, so it is somewhat similar to
Patchwork 2.0. But it has some nice functionality such as "git
range-diff"-like version comparison, and especially the patch importer
pushes each submitted series to git, complete with Reviewed-by tags and
the like.  The result is then used to run test scripts.  It also has a
REST API and a simple plugin API, so it should also be quite easy to
write new plugins to automatically parse syzbot or 0day emails and turn
them into test failures.

Paolo

[1] I have mentioned Patchew before on the kernel.org users mailing
list.  The largest project using Patchew is QEMU, whose "patch list"
page on patchew.org is at https://patchew.org/QEMU/.

> Less desirable options would affect people's workflows, which is
> something I'd like to avoid. One example is adding new commands which
> explicitly track the evolution of a feature in your local git
> repository.