From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28770 invoked by alias); 29 Nov 2012 16:32:31 -0000 Received: (qmail 28726 invoked by uid 22791); 29 Nov 2012 16:32:25 -0000 X-SWARE-Spam-Status: No, hits=-7.9 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 29 Nov 2012 16:32:21 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id qATGWErk028269 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 29 Nov 2012 11:32:15 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id qATGWDcx008583; Thu, 29 Nov 2012 11:32:14 -0500 Message-ID: <50B78E0C.50607@redhat.com> Date: Thu, 29 Nov 2012 16:32:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Eli Zaretskii CC: Joel Brobecker , gdb-patches@sourceware.org Subject: Re: proposal for branch patches after first release References: <20121129141415.GJ3540@adacore.com> <83wqx4v12l.fsf@gnu.org> In-Reply-To: <83wqx4v12l.fsf@gnu.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2012-11/txt/msg00878.txt.bz2 On 11/29/2012 04:14 PM, Eli Zaretskii wrote: >> Date: Thu, 29 Nov 2012 15:14:15 +0100 >> From: Joel Brobecker >> >> The proposal: >> >> Once a release has been published off a branch, any patch merged >> on the release branch requires a corresponding update in the >> NEWS file. > > That'd be a nuisance, IMO, because some of them might be > NEWS-unworthy. I agree. And this results in a bit awkward NEWS file, in that we don't normally document bug fixes there, but point releases are usually only about bug fixes. > An alternative would be to require some predictably formatted string > in the log entry or the commit message, which you then could grep for. A one line at the head would be quite standard, given people have come used to mail subject == git commit summary. This might be the easiest, though making this a "branch-only" requirement is very error prone. I wouldn't mind at all enforcing better and more self-contained commit log style, FWIW. > Yet another alternative would be to have a separate file, which > doesn't get into the tarball, with the relevant info, and request each > commit to the branch be accompanied with an entry for that file. We could also make better use of bugzilla for this. I had stated my opinion on this : "(...) I'm thinking more and more that we could get better release notes if all bugfixes had PRs filed for the correspondent bugs. At release time, we could find them in bugzilla, and say "this is the list of bugs that has been fixed". Other projects do this in their release announcements (glibc even maintains a lists of fixed PRs in their NEWS, but I'm not suggesting that), and I personally find it useful and interesting." But I don't think this one is mutually exclusive with the commit log idea. If people think the PR idea is too process burden for mainline, we could require this only for fixes that go into a release branch. E.g., tag the PRs with a special tag, e.g. "in-7.6.1". -- Pedro Alves