[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: changelog format
Re: changelog format
Tue, 17 Jan 2012 13:09:34 +0100
Hi Thien-Thi, thanks for having worked on this! I like you proposal very
much, with only a couple of nits nit (find them below).
On 01/17/2012 12:26 PM, Thien-Thi Nguyen wrote:
> () address@hidden (Karl Berry)
> () Fri, 23 Dec 2011 15:47:40 -0800
> I don't know if any of the (few) other people on bug-standards are
> interested, but in any case, if you want a (public :) archive of the
> thread, feel free to keep cc-ing the list.
> OK. Please find below a proposed patch to standards.texi.
> A link to another entry
> should be expressed as a date and an optional title, if the date is
> insufficient to uniquely identify the precedent. We recommend this
> over using a version control system commit identifier
I'd really, really like to see "in addition to" instead of "over"
used her, since VCS commit identifiers have at least an important
advantage of their own: they make it immediate for the reader to
refer to the linked entry, instead of having to rely on (say)
"git log --grep" or "git log --since=... --until=...". This is
even more true for GUI interfaces to the VCS, where VCS commit
identifiers might be automatically turned in clickable links.
> Here is a slightly-edited example from the Serveez top-level ChangeLog:
I think it would be nice to also ad another example with a slightly
different style. I propose this slightly edited version of the commit
message for the GNU coreutils commit 'c592a00f':
ls: be responsive to interrupts when color-listing large directories
This change fixes coreutils bug#10243.
Starting with commit adc30a83, when using --color, ls inhibited
interrupts to avoid corrupting the state of an output terminal.
However, for very large directories, that inhibition rendered ls
uninterruptible for too long, including a potentially long period
even before any output is generated.
* src/ls.c: Two phases of processing are time-consuming enough that
they can provoke this: the readdir loop and the printing loop. The
printing was supposed to be covered by a call to process_signals in
(print_name_with_quoting): ... but that call was mistakenly guarded
by a condition that might be false for many or even all files being
processed. Call process_signals unconditionally.
(print_dir): Also call process_signals in the readdir loop.
* NEWS (Bug fixes): Mention it.
Report by Arkadiusz Miskiewicz.
Re: changelog format, Thien-Thi Nguyen, 2012/01/17
Re: changelog format, Alfred M. Szmidt, 2012/01/17