[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4B506D89.7000708@s5r6.in-berlin.de>
Date: Fri, 15 Jan 2010 14:28:41 +0100
From: Stefan Richter <stefanr@...6.in-berlin.de>
To: David Miller <davem@...emloft.net>
CC: adi@...apodia.org, julia@...u.dk, nm127@...email.hu,
david.vrabel@....com, linux-usb@...r.kernel.org,
linux-kernel@...r.kernel.org, cocci@...u.dk
Subject: Re: Changelog quality
David Miller wrote:
> From: Stefan Richter <stefanr@...6.in-berlin.de>
> Date: Fri, 15 Jan 2010 10:17:08 +0100 (CET)
>
>> I on the other hold the opinion that the changelog has one purpose, to
>> describe the code change.
>
> %99 of a bug fix is the process and means by which the bug was found,
> therefore the "how was it found" is at least as important as how it is
> fixed.
Well, granted. The most important part of the changelog is perhaps the
"why", i.e. what problem is being fixed. How this problem was found is
often worth to describe as well. It may e.g. help to avoid future
occurrences or hint at further as yet unsolved issues. But how detailed
to document it is of course subjective; we could argue all day what is
signal and what is noise. (Which reminds me to stop being noisy and get
back to signal generation.)
> If the script in the commit bothers you, nobody forces you to read it
> or use it.
>
> If you want more clear markers around the script so you can skim
> past it more efficiently when reading the commit message, then ask
> for that.
I won't ask for that. The changelog format should not evolve into a
markup language.
--
Stefan Richter
-=====-==-=- ---= -====
http://arcgraph.de/sr/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists