Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits

[Joel Fernandes <joelaf@google.com>]

On Fri, Aug 23, 2019 at 12:19 PM Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
>
> Hi Thomas,
>
> On Fri, Aug 23, 2019 at 05:48:55PM +0200, Thomas Gleixner wrote:
> >
> > Yes, it's work for the submitter, but it's always work if the submitter
> > wants to have a proper trace.
>
> Here is where I disagree with you. As a patch submitter, I frankly could
> not care less about proper trace, history, etc. I might be putting cover

But that is exactly what the problem statement is. Doug does care
about tracing/history and wants that to be more robust etc.

> letter and outline the version changes, but I am doing that to reduce
> friction and help committer to land my change. Thant's it. And
> committers seem to have enough context from the provided version history
> and memory of the previous iterations.
>
> Who this new ID benefits most is a system integrator that is tracking
> all bits and pieces that are needed for their board to boot and work
> properly. Hopefully the system integrator is a good community citizen
> and not only wants to apply patches locally, but also make sure
> stragglers end up in mainline after all. But they need additional
> history to know whether the series was just forgotten, a new solution
> was adopted instead, and so on.
>
> It also can help maintainers who need (maybe years later) to research
> why particular change was made and whether there was additional
> discussion around certain point of the change.
>
> The process you outlined above (collecting msg ids from previous
> submissions, putting them into cover letter, etc) adds too much friction
> at submission time so that submitters will not actually do any of that.
> However having a git hook adding an ID to any new commit is much more
> workable.

I don't think a git-hook will solve what Doug is asking. There is
always some need for manual labor to add the metadata pointing to
previous patch posting. How does anyone but the patch submitter know
what the link/id/whatever of the previous patch posting or series is?
Unless git has some telepathy abilities that I did not know about.

Since my day job involves gerrit usage, I have used gerrit and
whenever I have a brand new patch for something; I have had to
manually add the old Change-Id to the new change so that gerrit
recognizes that it is linked to the old patch. That process is not
done by a hook. Sure the initial generation is through a hook, but
still.

thanks,

 - Joel