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

Dmitry Torokhov
2019-08-23T16:19:53Z

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
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.

Thanks.

--
Dmitry