From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29106 invoked by alias); 3 Jan 2011 17:45:58 -0000 Received: (qmail 29098 invoked by uid 22791); 3 Jan 2011 17:45:57 -0000 X-SWARE-Spam-Status: No, hits=-0.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_SOFTFAIL X-Spam-Check-By: sourceware.org Received: from mtaout21.012.net.il (HELO mtaout21.012.net.il) (80.179.55.169) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 03 Jan 2011 17:45:49 +0000 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0LEG00K00JXWWL00@a-mtaout21.012.net.il> for gdb-patches@sourceware.org; Mon, 03 Jan 2011 19:44:59 +0200 (IST) Received: from HOME-C4E4A596F7 ([77.127.127.157]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LEG00KU8JYWGH70@a-mtaout21.012.net.il>; Mon, 03 Jan 2011 19:44:59 +0200 (IST) Date: Mon, 03 Jan 2011 17:45:00 -0000 From: Eli Zaretskii Subject: Re: [patch] more comment cleanups In-reply-to: <20110103080610.GQ2396@adacore.com> To: Joel Brobecker Cc: hjl.tools@gmail.com, msnyder@vmware.com, mark.kettenis@xs4all.nl, gdb-patches@sourceware.org Reply-to: Eli Zaretskii Message-id: <83pqsdop9i.fsf@gnu.org> References: <4D1E60A0.1020601@vmware.com> <201012312312.oBVNC4fc013647@glazunov.sibelius.xs4all.nl> <4D1E732E.4090002@vmware.com> <834o9tq96f.fsf@gnu.org> <4D1F71B0.9060006@vmware.com> <20110103043359.GO2396@adacore.com> <20110103073452.GP2396@adacore.com> <20110103080610.GQ2396@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: 2011-01/txt/msg00045.txt.bz2 > Date: Mon, 3 Jan 2011 12:06:10 +0400 > From: Joel Brobecker > Cc: hjl.tools@gmail.com, msnyder@vmware.com, mark.kettenis@xs4all.nl, > gdb-patches@sourceware.org > > That could be useful indeed. The solution we use at AdaCore is to write > these entries only when checking in the CVS tree at sourceware. Internally, > we no longer use the ChangeLog (the information is stored inside the > revision log). That's an okay solution for developers, but end users don't necessarily access the repo, so the logs can still be useful for them. (Of course, the logs could be generated from the repo when the release is tarred, if the developers are disciplined enough to write log messages that can serve as ChangeLog entries as well.)