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 _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
