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 29357DC8 for ; Fri, 23 Aug 2019 19:38:42 +0000 (UTC) Received: from perceval.ideasonboard.com (perceval.ideasonboard.com [213.167.242.64]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6D03CE6 for ; Fri, 23 Aug 2019 19:38:41 +0000 (UTC) Date: Fri, 23 Aug 2019 22:38:32 +0300 From: Laurent Pinchart To: Thomas Gleixner Message-ID: <20190823193832.GE4791@pendragon.ideasonboard.com> References: <20190823151843.GH8130@mit.edu> <20190823161947.GA112509@dtor-ws> <20190823164602.GB112509@dtor-ws> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 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 09:17:04PM +0200, Thomas Gleixner wrote: > On Fri, 23 Aug 2019, Dmitry Torokhov wrote: > > On Fri, Aug 23, 2019 at 12:35:03PM -0400, Joel Fernandes wrote: > >> On Fri, Aug 23, 2019 at 12:19 PM Dmitry Torokhov wrote: > >>> 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. > > > > Doug here is not a submitter ;) > > Well, if he wants the changeids there then submitters need to insert them, > right? So it's work no matter what unless it can be automated with tooling. > > Guess what, how I inject the Link to the coverletter of the previous > version of a patch series? Definitely not manualy. Would you be able to share your method for automating this ? I'm sure many kernel developers could benefit from such automation (both those who insert links manually now, and those who don't insert links at all because doing it manually is too tedious). > So yes, if you want proper traceability then all involved people have to do > something. If it can be done with tooling fully automated, fine. If not, > it's work whatever method you chose. > > We cannot enforce the changeid thing in the community, but Google can > inforce it internally. So we give them a way to be traceable w/o plastering > the kernel logs with potentially useless information. > > That said, I'm fine with a Link as well, as long as it is public > accessible. If not, then the coverletter/discard area is the place to use. -- Regards, Laurent Pinchart