bug-standards
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: changelog format


From: Thien-Thi Nguyen
Subject: Re: changelog format
Date: Thu, 24 May 2012 22:49:46 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux)

() Stefano Lattarini <address@hidden>
() Thu, 24 May 2012 13:37:33 +0200

   > I don't agree that it's required

   There's a misunderstanding here.  I'm not saying that the
   rationale should be *mandated*, as in some cases it is truly
   overkill [...]

   What I'm saying is that, *when* a rationale about the why and
   how of a changeset is to be given, the proper place for it is
   the commit message; so, *when* it's needed, it *must* go in the
   commit message.

I understand completely now what you're saying, but still i disagree,
in defense of maintainer prerogative.

Consider some project w/ a "TODO file" which lists planned changes, and
archives completed changes, along with detailed design / implementation
(and re-design / re-impl :-D) notes, say.  That file is as good a place
as any for rationale information.  Of course, it would be good practice
to (distribute and) refer to it, just like it is good practice to refer
to bug reports, from the ChangeLog.

   > the "and why" is not universally highly valued).

   Which is real a shame.

I think that depends on the project and its maintainer(s).  Certainly,
many times ttn the historian wishes ttn the coding cowby had been more
rigorously forward-thinking in ChangeLog maintenance, but not always.
IME, those wishes are flanked by annoyance and regret but never shame.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]