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 671A0D82 for ; Fri, 28 Jun 2019 21:07:16 +0000 (UTC) Received: from bedivere.hansenpartnership.com (bedivere.hansenpartnership.com [66.63.167.143]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 15B573D0 for ; Fri, 28 Jun 2019 21:07:16 +0000 (UTC) Message-ID: <1561756033.3335.22.camel@HansenPartnership.com> From: James Bottomley To: Shuah Khan , ksummit-discuss@lists.linuxfoundation.org Date: Fri, 28 Jun 2019 14:07:13 -0700 In-Reply-To: <7b73e1b7-cc34-982d-2a9c-acf62b88da16@linuxfoundation.org> References: <7b73e1b7-cc34-982d-2a9c-acf62b88da16@linuxfoundation.org> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Fri, 2019-06-28 at 14:11 -0600, 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. > > Late entry, as I happened to come across this a day or two ago. It's always been the policy for most maintainers not to include these. They're usually context dependent like responses to reviews or how the series changed because of testing or API changes. Once they're placed into history devoid of context they'll become a distraction rather than useful information. Conversely, if they do contain informative content that's about the patch, not external context, that should have been placed into the changelog. So my other fear is that including version text will encourage people not to update the original changelog leading to potentially confusing changelogs requiring you to wade through all the versioning information. So I prefer we keep the current prevalent behaviour of removing the version change information and making sure the relevant parts are captured in the latest patch change log. James