From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1JB6JX-0003SN-DU for mharc-grub-devel@gnu.org; Sat, 05 Jan 2008 05:31:39 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JB6JV-0003Qo-Gq for grub-devel@gnu.org; Sat, 05 Jan 2008 05:31:37 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JB6JT-0003Ok-8y for grub-devel@gnu.org; Sat, 05 Jan 2008 05:31:36 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JB6JT-0003OU-2T for grub-devel@gnu.org; Sat, 05 Jan 2008 05:31:35 -0500 Received: from ns39764.ovh.net ([91.121.25.85] helo=nexedi.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JB6JS-0003MF-Md for grub-devel@gnu.org; Sat, 05 Jan 2008 05:31:34 -0500 Received: from [10.8.0.46] (unknown [10.8.0.46]) by nexedi.com (Postfix) with ESMTP id EC13C3EB24 for ; Sat, 5 Jan 2008 11:36:24 +0100 (CET) From: "Yoshinori K. Okuji" Organization: enbug.org To: The development of GRUB 2 Date: Sat, 5 Jan 2008 11:31:30 +0100 User-Agent: KMail/1.9.4 References: <20071231031229.1ilqcnpcwkc0oww8@webmail.spamcop.net> <200801050227.34479.okuji@enbug.org> <1199498537.25368.25.camel@dv> In-Reply-To: <1199498537.25368.25.camel@dv> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200801051131.31368.okuji@enbug.org> X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 3) Subject: Re: Testing on PowerMac G4 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jan 2008 10:31:37 -0000 On Saturday 05 January 2008 03:02, Pavel Roskin wrote: > On Sat, 2008-01-05 at 02:27 +0100, Yoshinori K. Okuji wrote: > > On Thursday 03 January 2008 16:28, Pavel Roskin wrote: > > > >> Linux style description. The first line is the synopsis. If it > > > >> doesn't fit 72 characters, the patch is a candidate for splitting. > > > >> Then an empty line. Then a more detailed description of the patch, > > > >> including the motivation behind the changes. The list of the > > > >> affected files can be generated by the version control system. > > > > > > > > Looks good. But I guess you'll have to convince Marco and Okuji > > > > about this :-) > > > > > > Sure, it's in my TODO list :) > > > > I do not think automatically generated logs can be as precise as being > > made by human. > > > > Anyway, there is no reason that you shouldn't write a detailed > > description in ChangeLog. Indeed, I myself sometimes do that, when I make > > a big change or something hard to understand. > > We are talking about a changeset from 2007-02-21 (the earliest of them), > where the ChangeLog entry has the usual "calculate this" and "rename > this to that". It took me hours of experiments to figure out that the > intention was to load the core image and the modules much lower in the > memory. Sure, it looks trivial when explained. > > And by the way, a trivial change that doesn't modify anything as > fundamental as memory layout could be described in very similar terms. > There is no way to see how profound changes are and whether they are > relevant to the observed problems. You are right, but this is nothing with ChangeLog itself. If one did not write a good commit message, the same thing happens with any kind of system. > Detailed descriptions may be useful in many cases, but in my opinion, > they should be secondary to high level descriptions. Huh? You only think about the technical aspect. Note that ChangeLog is not only for technical purpose. http://www.gnu.org/prep/maintain/html_node/Legally-Significant.html#Legally-Significant Okuji