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 63F0DE28 for ; Fri, 23 Aug 2019 20:02:30 +0000 (UTC) Received: from mail-lj1-f176.google.com (mail-lj1-f176.google.com [209.85.208.176]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 65334E6 for ; Fri, 23 Aug 2019 20:02:29 +0000 (UTC) Received: by mail-lj1-f176.google.com with SMTP id x3so9940113lji.5 for ; Fri, 23 Aug 2019 13:02:29 -0700 (PDT) MIME-Version: 1.0 References: <20190823013619.GA8130@mit.edu> <20190823151843.GH8130@mit.edu> <20190823161947.GA112509@dtor-ws> <20190823164602.GB112509@dtor-ws> In-Reply-To: From: Christian Brauner Date: Fri, 23 Aug 2019 22:02:16 +0200 Message-ID: To: Thomas Gleixner Content-Type: multipart/alternative; boundary="0000000000001acbc50590ce4934" 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: , --0000000000001acbc50590ce4934 Content-Type: text/plain; charset="UTF-8" On Fri, Aug 23, 2019, 21:17 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. > > 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 > A link is definitely more helpful then the change-id. Quite a few maintainers are already making use of links to various sites anyway so I don't see a good reason not allow Links to Gerrit or whatever. accessible. If not, then the coverletter/discard area is the place to use. > Right, change-id should go after --- which is also what Dmitry Vyukov suggested. One thing I wonder though. What's the ultimate goal here? Enabling people to review on Gerrit and lkml simultaneously? I mean, apart from tracking versions of patch series/patches this can't be all, right? We can already do that right now and I'm already doing that when applying stuff to my tree: inserting the link to the version of the patch set I applied and linking to the previous version in each new version of the patchset. That could also be automated. So is allowing reviews both on Gerrit or whatever the goal here and if so how do we ensure that lkml sees all reviews? Christian --0000000000001acbc50590ce4934 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


= On Fri, Aug 23, 2019, 21:17 Thomas Gleixner <tglx@linutronix.de> 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
> > <dmitry.torokhov@gmail.com> wrote:
> > > On Fri, Aug 23, 2019 at 05:48:55PM +0200, Thomas Gleixner wr= ote:
> > > >
> > > > Yes, it's work for the submitter, but it's alwa= ys work if the submitter
> > > > wants to have a proper trace.
> > >
> > > Here is where I disagree with you. As a patch submitter, I f= rankly could
> > > not care less about proper trace, history, etc. I might be p= utting 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,<= br> right? So it's work no matter what unless it can be automated with tool= ing.

Guess what, how I inject the Link to the coverletter of the previous
version of a patch series? Definitely not manualy.

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

A link = is definitely more helpful then the change-id.
Quite= a few maintainers are already making use of links to various sites anyway = so I don't see a good reason not allow Links to Gerrit or whatever.

=
accessible. If not, then the coverletter/discard area is the place to use.<= br>

R= ight, change-id should go after --- which is also what Dmitry Vyukov sugges= ted.

One thing I wonder = though. What's the ultimate goal here?
Enabling = people to review on Gerrit and lkml simultaneously?
= I mean, apart from tracking versions of patch series/patches this can't= be all, right?
We can already do that right now and= I'm already doing that when applying stuff to my tree: inserting the l= ink to the version of the patch set I applied and linking to the previous v= ersion in each new version of the patchset.
That cou= ld also be automated.
So is allowing reviews both on= Gerrit or whatever the goal here and if so how do we ensure that lkml sees= all reviews?

Christian<= /div>
--0000000000001acbc50590ce4934--