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 55EC349B5 for ; Mon, 1 Jul 2019 15:48:29 +0000 (UTC) Received: from perceval.ideasonboard.com (perceval.ideasonboard.com [213.167.242.64]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0A2DA782 for ; Mon, 1 Jul 2019 15:48:27 +0000 (UTC) Date: Mon, 1 Jul 2019 18:48:06 +0300 From: Laurent Pinchart To: Thomas Gleixner Message-ID: <20190701154806.GF5018@pendragon.ideasonboard.com> References: <7b73e1b7-cc34-982d-2a9c-acf62b88da16@linuxfoundation.org> <20263.1561993564@warthog.procyon.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Cc: ksummit-discuss@lists.linuxfoundation.org Subject: Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Hi Thomas, On Mon, Jul 01, 2019 at 05:40:58PM +0200, Thomas Gleixner wrote: > On Mon, 1 Jul 2019, David Howells wrote: > > Shuah Khan wrote: > > > In a recent patch discussion, I learned that some maintainers would like > > > to see patch version changes in the commit log. > > > > > > I went looking in the git log and found a handful of recent commits with > > > "Changes since" type information in the commit logs. It appears to be > > > maintainer preference and a recent trend. > > > > > > I see the value in including the information. It can be informative > > > and valuable for future work in the area. > > > > > > Is this something that we would like to see in all commits going forward? If > > > so, updating submitting patch documentation and making > > > sure the version information evolves from "informal" to more formal > > > nature that fits in with the commit logs would be helpful. > > > > > > Making sure it doesn't get out of hand and commit logs don't > > > become too long to be useful would also be helpful. > > > > I put the changelog in the cover note (ie. patch 0) since if there's more than > > one patch there may well be changes that span multiple patches. Whoever's > > That's a pain. I'd have to go back and forth to find that information. If > the v$N info is in the patch itself, then it clearly shows what the scope > of the change is in that particular patch, e.g. just fixing up the typo or > some structural change. I agree with you in general (I've asked multiple submitters to move changelogs to individual patches in the past), except for high-level change descriptions at the series level that don't naturally fit in one particular patch. I tend myself to summarise the most important changes in the cover letter, so someone reviewing the whole series will have a global view of the changes at the beginning, and will also find the relevant information in each patch. I however understand that this is possibly more work for the submitter and my thus get frowned upon, but I find it useful during review. > And no, this is not about convenience for the submitter. It's about > convenience for the reviewer/maintainer. The goal must be to make their > life as simple as possible not the other way round. > > > doing the merge could include this in the merge description. > > That does not help for patch series which are applied directly from mail. -- Regards, Laurent Pinchart