All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Yoshinori K. Okuji" <okuji@enbug.org>
To: The development of GRUB 2 <grub-devel@gnu.org>
Subject: Re: Testing on PowerMac G4
Date: Sat, 5 Jan 2008 11:31:30 +0100	[thread overview]
Message-ID: <200801051131.31368.okuji@enbug.org> (raw)
In-Reply-To: <1199498537.25368.25.camel@dv>

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



  reply	other threads:[~2008-01-05 10:31 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-31  8:12 Testing on PowerMac G4 Pavel Roskin
2007-12-31  8:45 ` Jan Nieuwenhuizen
2007-12-31 22:37   ` Pavel Roskin
2007-12-31 23:34     ` Robert Millan
2008-01-02  6:46       ` Pavel Roskin
2008-01-02 10:32         ` Robert Millan
2008-01-03  8:09           ` Pavel Roskin
2008-01-03 12:11             ` Robert Millan
2008-01-03 15:28               ` Pavel Roskin
2008-01-03 15:57                 ` Robert Millan
2008-01-03 16:23                   ` Pavel Roskin
2008-01-04 12:32                     ` Robert Millan
2008-01-04 12:54                       ` Robert Millan
2008-01-04 18:26                       ` Pavel Roskin
2008-01-04 20:37                         ` Robert Millan
2008-01-05  1:45                           ` Yoshinori K. Okuji
2008-01-05 11:43                             ` Robert Millan
2008-01-05  2:10                           ` Pavel Roskin
2008-01-05 11:45                             ` Robert Millan
2008-01-05  1:27                 ` Yoshinori K. Okuji
2008-01-05  2:02                   ` Pavel Roskin
2008-01-05 10:31                     ` Yoshinori K. Okuji [this message]
2008-01-05 11:46                   ` Robert Millan
2007-12-31 14:04 ` Robert Millan
2007-12-31 22:58   ` Pavel Roskin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200801051131.31368.okuji@enbug.org \
    --to=okuji@enbug.org \
    --cc=grub-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.