From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11807 invoked by alias); 15 Aug 2014 08:48:30 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 11798 invoked by uid 89); 15 Aug 2014 08:48:29 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Fri, 15 Aug 2014 08:48:28 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s7F8mLmF002151 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 15 Aug 2014 04:48:21 -0400 Received: from blade.nx (ovpn-116-116.ams2.redhat.com [10.36.116.116]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s7F8mKGD026012; Fri, 15 Aug 2014 04:48:20 -0400 Received: by blade.nx (Postfix, from userid 1000) id BFCC22640CB; Fri, 15 Aug 2014 09:48:19 +0100 (BST) Date: Fri, 15 Aug 2014 08:48:00 -0000 From: Gary Benson To: Joel Brobecker Cc: Mike Frysinger , gdb@sourceware.org, Andreas Arnez Subject: Re: ChangeLogs in commit messages Message-ID: <20140815084819.GB30130@blade.nx> References: <20140814083231.GA6283@blade.nx> <6036430.RnprRWgZmF@vapier> <20140814131206.GA12746@blade.nx> <20140814132939.GH4924@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140814132939.GH4924@adacore.com> X-IsSubscribed: yes X-SW-Source: 2014-08/txt/msg00048.txt.bz2 Joel Brobecker wrote: > > Do you mean #4 (changelog entries with no path/author-date) or are > > you proposing new option #5 (no changelog in the commit message at > > all)? #5 would suit me too. > > No, I strongly object to #5. The ChangeLog entries are part of the > email to be sent along with the patch to be reviewed, We had that > discussion many many years ago, and at the time, people wanted the > CL entry in the email, rather than as a diff. This discussion is starting to blur the lines between "what is in the commit message" and "what is in the gdb-patches email". Right now, the two are the same, especially if you use git-send-email, but I don't think git-send-email convenience is a valid reason to say that ChangeLog entries need to be in the commit message. If we wanted a situation where gdb-patches emails have ChangeLog entries but commit messages do not then we could surely script that. > And finally, I find the CL entry to be useful to have when I review > revision logs. Noted. My work on GDB mostly involves _generating_ commits, so I have a natural bias towards removing things that make that difficult (and ChangeLogs are an easy target). I do recognise, however, that some people's work also involves _consuming_ commits (for creating release branches, or for distro integration) so when I hear Joel and Sergio stating the cases for a) ChangeLog files to exist, and b) ChangeLog entries to be included in commit messages I have to admit that their arguments carry more weight than my "everything would be so much more convenient for me if ChangeLogs went away". So I think we should stop discussing the removal of ChangeLogs, in this thread anyway. Andreas Arnez pointed out that Joel previously mentioned generating the actual ChangeLog files from the commit messages, here: https://sourceware.org/ml/gdb-patches/2014-01/msg00578.html This sounds like an interesting idea, but we really would have to standardize on a particular format, and I think #1 (path and author- date headers) is the only option that could realistically work. If we standardize on this now (and put some checks on the server to weed out bad messages) then come December we'll have four months of commit messages we can use to check whether we can correctly replicate the ChangeLog files. And, if we can, we can consider omitting the files from the repo and generating them as needed for tarballs. How does this sound? Cheers, Gary -- http://gbenson.net/