public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andy Isaacson <adi@hexapodia.org>
To: Julia Lawall <julia@diku.dk>
Cc: Stefan Richter <stefanr@s5r6.in-berlin.de>,
	N??meth M??rton <nm127@freemail.hu>,
	David Vrabel <david.vrabel@csr.com>,
	linux-usb@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
	cocci@diku.dk
Subject: Re: Changelog quality (was Re: [PATCH] uwb: make USB device id constant)
Date: Thu, 14 Jan 2010 17:03:15 -0800	[thread overview]
Message-ID: <20100115010315.GA29093@hexapodia.org> (raw)
In-Reply-To: <Pine.LNX.4.64.1001131633490.26518@ask.diku.dk>

On Wed, Jan 13, 2010 at 04:38:22PM +0100, Julia Lawall wrote:
> > When you write a changelog, keep your audience in mind:
> > 
> >   - Developers, distributors, advanced users want to learn what a new
> >     release brings.  (OK, this audience stops reading after the initial
> >     headline of a "make XYZ table constant" commit.  Which just means
> >     that all the rest of the changelog is fluff that can be omitted.)
> > 
> >   - Developers, maintainers etc. want to understand years later why the
> >     code is how it is.  (For them, a commit like that is sufficiently
> >     described by the headline as well.)
> 
> Not surprisingly, I don't agree about this one.  I recall a series of 
> patches that said something like "used a script to change down/up to 
> mutexes".  The script wasn't included, not all down/ups were changed to 
> mutexes, and in short there was no understandable trace of why the change 
> was made where it was.  Perhaps that is a pathological example, but it is 
> not necessarily obvious in advance what needs precise documentation and 
> what does not.

I agree with Julia, at least in some cases.  Having the semantic patch
present when it's 5 or 10 lines long and clearly explains the intended
change is incredibly valuable for review.  Sometimes, the script is the
clearest way to indicate your intent -- I'd much rather see a changelog
that says "s/FOO/BAR/g" than "Change FOO to BAR everywhere".

For example, look at 5d66fe92.  The semantic patch is blissfully,
incredibly clear.  It makes the sun shine down through the clouds, the
birds sing, and the kzalloc align.  It's 10 lines long and is quite
intuitive and explanatory.  In that case, I think it's clear that the
spatch is worth the changelog space it takes up, even though the
changelog is larger than the diff by quite a margin.

On the other hand, the patch that started this thread is a
counterexample, to me.  The correctness of the constification is only
tenuously attested, for me at least, by the semantic patch.  The spatch
is really long compared to the diff, and complicated to read.

So, I think it's a balancing act.  I've been very happy to see spatches
in some of Julia's posts, and I've also found some of the more
voluminous spatches in changelogs to be more noise than signal.

-andy

  parent reply	other threads:[~2010-01-15  1:03 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-12  7:49 [PATCH] uwb: make USB device id constant Németh Márton
2010-01-12 16:10 ` David Vrabel
2010-01-12 16:57   ` Németh Márton
2010-01-13 14:59     ` Changelog quality (was Re: [PATCH] uwb: make USB device id constant) Stefan Richter
2010-01-13 15:38       ` Julia Lawall
2010-01-13 17:06         ` Changelog quality Stefan Richter
2010-01-13 17:29           ` Alan Stern
2010-01-13 17:44             ` Greg KH
2010-01-13 18:04               ` Alan Stern
2010-01-13 19:52                 ` Greg KH
2010-01-14  5:24                   ` Németh Márton
2010-01-14  6:05                     ` Julia Lawall
2010-01-14  8:07                       ` Stefan Richter
2010-01-14  8:26                     ` Dmitry Torokhov
2010-01-13 19:19               ` Geert Uytterhoeven
2010-01-13 17:49             ` Bartlomiej Zolnierkiewicz
2010-01-13 18:22               ` Stefan Richter
2010-01-15  1:03         ` Andy Isaacson [this message]
2010-01-15  8:13           ` Changelog quality (was Re: [PATCH] uwb: make USB device id constant) Stefan Richter
2010-01-15  8:24             ` Changelog quality David Miller
2010-01-15  8:50               ` Stefan Richter
2010-01-15  8:54                 ` David Miller
2010-01-15  9:17                   ` Stefan Richter
2010-01-15  9:22                     ` David Miller
2010-01-15  9:43                       ` Julia Lawall
2010-01-15  9:49                         ` Pekka Enberg
2010-01-15 10:05                           ` Julia Lawall
2010-01-15 11:08                             ` Mark Brown
2010-01-15 12:06                               ` Julia Lawall
2010-01-15 12:44                                 ` Pekka Enberg
2010-01-15 13:10                                   ` Julia Lawall
2010-01-15 12:45                                 ` Stefan Richter
2010-01-15 12:52                                   ` Pekka Enberg
2010-01-15 13:39                                 ` Mark Brown
2010-01-15 16:49                                   ` SmPL scripts into build environment? (was: Changelog quality) Németh Márton
2010-01-18 10:58                                     ` SmPL scripts into build environment? Michal Marek
2010-01-18 11:22                                       ` Julia Lawall
2010-01-15 13:28                       ` Changelog quality Stefan Richter

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=20100115010315.GA29093@hexapodia.org \
    --to=adi@hexapodia.org \
    --cc=cocci@diku.dk \
    --cc=david.vrabel@csr.com \
    --cc=julia@diku.dk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=nm127@freemail.hu \
    --cc=stefanr@s5r6.in-berlin.de \
    /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