Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Daniel Jacobowitz <drow@false.org>
To: "Brian J. Fox" <bfox@ai.mit.edu>
Cc: Denis PILAT <denis.pilat@st.com>,
	Chet Ramey <chet.ramey@case.edu>, 	Eli Zaretskii <eliz@gnu.org>,
	gdb-patches@sources.redhat.com, 	bash-maintainers@gnu.org
Subject: Re: [patch-readline] history file reading
Date: Tue, 21 Mar 2006 19:55:00 -0000	[thread overview]
Message-ID: <20060321164105.GA29111@nevyn.them.org> (raw)
In-Reply-To: <C04569E0.30716%bfox@ai.mit.edu>

On Tue, Mar 21, 2006 at 08:29:20AM -0800, Brian J. Fox wrote:
> > From: Daniel Jacobowitz <drow@false.org>
> > Date: Tue, 21 Mar 2006 09:58:42 -0500
> > To: Denis PILAT <denis.pilat@st.com>, Chet Ramey <chet.ramey@case.edu>
> > Cc: Eli Zaretskii <eliz@gnu.org>, <gdb-patches@sources.redhat.com>,
> > <bash-maintainers@gnu.org>
> > Subject: Re: [patch-readline] history file reading
> > 
> > Our ChangeLog entries have two spaces between date and name, and two
> > between name and date.  The indented portion starts with a tab on every
> > line.  The first character should usually be capitalized.  Also, they
> > cover only "what" and not "why".
> 
> Since when do ChangeLog entries not say "why"?  Without this information, it
> is impossible to tell if the change needs to stay or not in the future.
> 
> I've certainly always included "why" in my ChangeLog entries.
> 
> Is this a personal preference, or are you quoting a new GNU mantra?

In the GNU projects I've worked in, this is the usual interpretation of
the existing GNU coding standards:

http://www.gnu.org/prep/standards/html_node/Change-Log-Concepts.html#Change-Log-Concepts

  There's no need to describe the full purpose of the changes or how they
  work together. If you think that a change calls for explanation, you're
  probably right. Please do explain it - but please put the explanation in
  comments in the code, where people will see it whenever they see the
  code. For example, New function is enough for the change log when you
  add a function, because there should be a comment before the function
  definition to explain what it does.

And from GCC:

See also what the GNU Coding Standards have to say about what goes in
ChangeLogs; in particular, descriptions of the purpose of code and
changes should go in comments rather than the ChangeLog, though a
single line overall description of the changes may be useful above the
ChangeLog entry for a large batch of changes.

-- 
Daniel Jacobowitz
CodeSourcery


  reply	other threads:[~2006-03-21 16:42 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-03-17  0:15 [patch-readline] history file generation on minGW host Denis PILAT
2006-03-17  0:26 ` Daniel Jacobowitz
2006-03-17  0:31   ` Denis PILAT
2006-03-17 16:07 ` Eli Zaretskii
2006-03-17 19:12   ` Denis PILAT
2006-03-17 19:37     ` Chet Ramey
2006-03-21 15:30   ` [patch-readline] history file reading Denis PILAT
2006-03-21 15:32     ` Chet Ramey
2006-03-21 15:38       ` Daniel Jacobowitz
2006-03-21 16:29         ` Andreas Schwab
2006-03-21 16:42           ` Bob Rossi
2006-03-21 16:46             ` Daniel Jacobowitz
2006-03-23  4:55             ` Eli Zaretskii
2006-03-21 19:52         ` Brian J. Fox
2006-03-21 19:55           ` Daniel Jacobowitz [this message]
2006-03-21 20:02           ` Andreas Schwab
2006-03-23  5:15             ` Eli Zaretskii
2006-03-23  4:37         ` Eli Zaretskii

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=20060321164105.GA29111@nevyn.them.org \
    --to=drow@false.org \
    --cc=bash-maintainers@gnu.org \
    --cc=bfox@ai.mit.edu \
    --cc=chet.ramey@case.edu \
    --cc=denis.pilat@st.com \
    --cc=eliz@gnu.org \
    --cc=gdb-patches@sources.redhat.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox