From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4816 invoked by alias); 30 Nov 2012 09:15:15 -0000 Received: (qmail 4804 invoked by uid 22791); 30 Nov 2012 09:15:14 -0000 X-SWARE-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_DNSWL_NONE,RCVD_IN_HOSTKARMA_NO,SPF_SOFTFAIL X-Spam-Check-By: sourceware.org Received: from mtaout22.012.net.il (HELO mtaout22.012.net.il) (80.179.55.172) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 30 Nov 2012 09:15:08 +0000 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MEA00G00MXYYH00@a-mtaout22.012.net.il> for gdb-patches@sourceware.org; Fri, 30 Nov 2012 11:14:59 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MEA00GHIN0YYE10@a-mtaout22.012.net.il>; Fri, 30 Nov 2012 11:14:59 +0200 (IST) Date: Fri, 30 Nov 2012 09:15:00 -0000 From: Eli Zaretskii Subject: Re: proposal for branch patches after first release In-reply-to: <20121129210440.GL3581@adacore.com> To: Joel Brobecker Cc: palves@redhat.com, gdb-patches@sourceware.org Reply-to: Eli Zaretskii Message-id: <83boefv4e3.fsf@gnu.org> References: <20121129141415.GJ3540@adacore.com> <83wqx4v12l.fsf@gnu.org> <50B78E0C.50607@redhat.com> <20121129210440.GL3581@adacore.com> X-IsSubscribed: yes 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/msg00913.txt.bz2 > Date: Thu, 29 Nov 2012 22:04:40 +0100 > From: Joel Brobecker > Cc: Eli Zaretskii , gdb-patches@sourceware.org > > > > 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. > > While I agree it's a good idea to move towards this principle, > and for both head & branch, I think there is too much of a chance > for oversights. We post all patches here, most of them undergo a review before being pushed, so we could keep an eye on that. CVS allows one to change the commit message, so we could do that retrospectively if someone forgets (unless the git conversion will become confused by such changes). If we keep these records on ChangeLog, the fix is even simpler: just make another commit with a proper description. > I also think that having the information spread out, be it in > the revision logs, or in a bugs database, makes it hard for anyone > who wants to figure out what changes exactly a minor release > contains and for what purpose. This is an argument in favor of ChangeLog. > For all these reasons, I think that having the developer write up > the description himself, with approval from Eli, and put it somewhere > in a file, would be best. If we want to call it known-problems or > anything else, instead of putting that info in the NEWS files, > that would be fine as well. This, too, would be fine with me.