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 9B47A2E82 for ; Wed, 28 Aug 2019 12:38:46 +0000 (UTC) Received: from mail-qt1-f193.google.com (mail-qt1-f193.google.com [209.85.160.193]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 033FE13A for ; Wed, 28 Aug 2019 12:38:45 +0000 (UTC) Received: by mail-qt1-f193.google.com with SMTP id k13so2727179qtm.12 for ; Wed, 28 Aug 2019 05:38:45 -0700 (PDT) MIME-Version: 1.0 References: <20190827134836.GB25038@kroah.com> <20190827153344.GC534@kroah.com> <20190827195351.GA30710@kroah.com> <20190828090837.GA31704@kroah.com> In-Reply-To: <20190828090837.GA31704@kroah.com> From: Joel Fernandes Date: Wed, 28 Aug 2019 08:38:33 -0400 Message-ID: To: Greg Kroah-Hartman Content-Type: text/plain; charset="UTF-8" Cc: Barret Rhoden , ksummit , 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 Wed, Aug 28, 2019 at 5:08 AM Greg Kroah-Hartman wrote: > > On Tue, Aug 27, 2019 at 05:34:47PM -0400, Joel Fernandes wrote: > > On Tue, Aug 27, 2019 at 3:53 PM Greg Kroah-Hartman > > wrote: > > > On Tue, Aug 27, 2019 at 02:55:28PM -0400, Konstantin Ryabitsev wrote: > > > > On Tue, 27 Aug 2019 at 11:33, Greg Kroah-Hartman > > > > wrote: > > > > > > Link: https://lkml.kernel.org/$Message-ID > > > > > > > > > > > > then you have your UUID tag. The tip bot sends you a reply based on that > > > > > > tag and I know you got some of them already. > > > > > > > > > > I'm using: > > > > > Link: https://lore.kernel.org/r/$message-id > > > > > > > > > > should we standardize on the lkml one instead as it's shorter? The lore > > > > > one handles any message id that is on any mailing list it handles, is > > > > > the lkml one the same? > > > > > > > > It's the exact same system and the /r/ is always required. I prefer > > > > lore.kernel.org because it doesn't imply that the message is going to > > > > be on the LKML (i.e. it can be on a list that isn't even hosted on > > > > vger.kernel.org). > > > > > > > > So, my recommendation is Link: https://lore.kernel.org/r/$message-id > > > > > > Great, will stick with that one, thanks. > > > > I am thinking of how to make this automagic and useful for me. My plan > > is (and ymmv): > > > > When I write a patch, have a git hook generate "Message-Id" in my > > patch changelog itself when it is written using Greg/Andrew's > > make_message_id. This Message-Id is not the final message-id and is > > just for reference purposes for later processing. Then when sending > > it, after git format-patch I will do a few things: > > (a) Consult the archive to check the highest value of N for which > > Message-Id- does not exist > > (b) Add Message-Id: Message-Id- to the patch header so git > > send-email uses this as the Message-Id- > > (c) Add this Message-Id- as a Link: to the changelog; Possibly > > removing Message-Id link. > > (d) Remove the original "Message-Id" without the - from the > > changelog since it has no purpose. > > (e) Send the patch > > Wow, what an overly complex thing for something that should be trivial > to do... The idea is to make it trivial. All of the steps above are automatic and scripted, that's the whole point of what I was saying - to make it automatic. If it is not automated, then it is unlikely to be adopted widely or unlikely to stick. The final user will experience it as trivial. > How about this, when sending a v2, you have it be in response to the v1 > patch? Same for v3, have it be in response for the v2 one. And so on. If I remember correctly, the in-reply-to method has drawbacks and is not always desired especially when dealing with a whole series. In such a case of a whole series, the individual patches are replies to the cover-letter (as --thread of git format-patch does); they should not be replies to old versions of that patch; otherwise the threading looks really weird and confusing. Plus your response suggestion still does not make it automatic. How does sending of a v2 know that it is reply to a v1? Some metadata has to be stored in your git tree for that. That's the whole point of the steps I listed above. > Then, when the "final" patch is added, the message id of that will be > committed to the tree with the git hook that has been posted here, and > then, if someone _REALLY_ wants to go look up past history of versions, > they can see it all linked together in a nice pretty tree on > lore.kernel.org or elsewhere. > > And really, this whole discussion has been for the VERY RARE case of > when someone wants to do some code spelunking and try to figure out > older versions of a patch history before it was committed and they don't > feel like searching for the author's name instead. The HUGE majority of > kernel developers never actually care about this as they don't have to > do it. I think it is a frequent use case that folks want to look up old revisions of a patch and follow the review/discussions of previous revisions to know the history of how a patch got to where it is. I think it can be really useful. thanks, - Joel