From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 0D7FBFE0 for ; Fri, 23 Aug 2019 16:19:53 +0000 (UTC) Received: from mail-pf1-f175.google.com (mail-pf1-f175.google.com [209.85.210.175]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id ACCE489B for ; Fri, 23 Aug 2019 16:19:52 +0000 (UTC) Received: by mail-pf1-f175.google.com with SMTP id s11so828637pfe.6 for ; Fri, 23 Aug 2019 09:19:52 -0700 (PDT) Date: Fri, 23 Aug 2019 09:19:47 -0700 From: Dmitry Torokhov To: Thomas Gleixner Message-ID: <20190823161947.GA112509@dtor-ws> References: <20190823013619.GA8130@mit.edu> <20190823151843.GH8130@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: Joel Fernandes , Barret Rhoden , ksummit , Greg Kroah-Hartman , Jonathan Nieder , Tomasz Figa , Han-Wen Nienhuys , Theodore Tso , David Rientjes , Dmitry Torokhov , Dmitry Vyukov Subject: Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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