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 9A428FA6 for ; Fri, 23 Aug 2019 16:35:16 +0000 (UTC) Received: from mail-qk1-f172.google.com (mail-qk1-f172.google.com [209.85.222.172]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 20DFB67F for ; Fri, 23 Aug 2019 16:35:16 +0000 (UTC) Received: by mail-qk1-f172.google.com with SMTP id s145so8668060qke.7 for ; Fri, 23 Aug 2019 09:35:16 -0700 (PDT) MIME-Version: 1.0 References: <20190823013619.GA8130@mit.edu> <20190823151843.GH8130@mit.edu> <20190823161947.GA112509@dtor-ws> In-Reply-To: <20190823161947.GA112509@dtor-ws> From: Joel Fernandes Date: Fri, 23 Aug 2019 12:35:03 -0400 Message-ID: To: Dmitry Torokhov Content-Type: text/plain; charset="UTF-8" Cc: 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: , On Fri, Aug 23, 2019 at 12:19 PM Dmitry Torokhov 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