Re: Linking topic merges to mailing list threads

From: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
Date: Sep 30, 2024, 16:57 UTC
Message-ID: <20240930-sly-outstanding-boar-c16e9c@lemur>
In-Reply-To: <CAJoAoZ=4ARuH3aHGe5yC_Xcnou_c396q_ZienYPY7YnEzZcyEg@mail.gmail.com>

On Mon, Sep 30, 2024 at 09:21:11AM GMT, Emily Shaffer wrote:

Show 13 quoted lines

> Hi all,
> 
> We've been wanting to gather metrics on Git's code review process -
> how long it takes from first contact on list to merge, how many
> iterations are needed, time between iterations, etc. One missing link
> is the actual merge time in `next` and `master` - a human can infer
> the link between the patch and the mailing list thread, but it's more
> challenging for a script to do it.
> 
> Would it be possible to modify the maintainer workflow to include a
> link to the cover letter as merged in the merge commit message (or the
> link to the latest iteration of the patch if it's a single-patch
> change)? What issues could come up with that workflow?

One of the goals of b4 on the kernel side of things was to promote the use of cover letters as merge commit templates, but this requires buy-in from maintainers. It also doesn't really work for single-patch series.

For example, applying a series with "b4 shazam -M" will:

- fetch the series into FETCH_HEAD
- use the cover letter as the basis for the merge commit message
- insert the links to the source of the series
- open up the editor, allowing the maintainer to edit the merge commit message

Here's an example of such merge:

https://git.kernel.org/pub/scm/utils/b4/b4.git/commit/?id=b6b73918d94985bb2a017784fc14e013b36b38d0

> I guess one is that we could move from lore.kernel.org to something
> else, like we saw the migration from public-inbox.org some years ago.
> But the Message-ID was preserved between the two archives, so maybe
> it's enough to include the Message-ID in the merge commit?

This should be sufficient, yes, because you should still be able to find the origin thread even if lore.kernel.org is defunct at some point.

> Another is, of course, the added burden on the maintainer. But maybe there
> is some script that is already used that we can modify to make the extra
> load negligible?

There is. :)

> (Or, even better, if anybody else is already successfully measuring
> these kinds of metrics without such a reference, could you let me know
> how you're doing it? :) )

On the kernel side, any time the topic of metrics comes up, it gets immediately bogged down in "how much tracking is okay and how much is spying" kinds of discussions that have never resulted in anything, really.

-K