Emily Shaffer <nasamuffin@xxxxxxxxxx> writes:
> 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 ...
I suspect that there is no need for any workflow change, as all the
necessary information should be available from public sources.
The first-parent chain from 'next' (or 'master' for that matter)
already record when they got merged. From there, C^1..C^2 are
the commit objects that were merged. notes/amlog knows where
they came from (i.e. their Message-Id). From lore/public-inbox
you can find out how the iterations of topics went, as long as
the topics are threaded properly (and if not, that would not be
fixable with any maintainer workflow changes), just like how b4 can
figure all of that out.
Ahh, nothing officially documents amlog and that is what you are
missing. It would be very nice if somebody, preferrably somebody
other than I, after trying the "maintainer workflow" by pretending
to be a maintainer for a day or two with the new info revealed here,
updates the Documentation/howto/maintain-git.txt file with the
information below.
The script post-appplypatch found in the todo branch is made
available as .git/hooks/post-applypatch so that "git am" knows to
run it after creating a commit out of an e-mailed patch. It
populates a mapping from commit object name to "Message-Id" of
individual patch.
"git rebase" knows how to propagate this across rebases because
I have
[notes] rewriteref = refs/notes/amlog
in the .git/config (which means I have to use rebase not cherry-pick
even when I am touching a single patch, as cherry-pick does not
preserve notes by design).
Now I think you should have everything, together with what is
already in Documentation/howto/maintain-git.txt, piece them together
to illustrate the life of a patch series.
As I do not publish reflog for 'seen', you cannot do "when was the
topic got picked up to 'seen'?", but as far as I am concerned, it is
by design. Being in 'seen' does not mean anything other than I
happened to have seen it, or saw that somebody indicate interest in
it.
Thanks.
