[RFC] Policy change for ChangeLog

Neil Williams linux at codehelp.co.uk
Fri Dec 2 16:45:33 EST 2005


On Friday 02 December 2005 8:59 pm, Derek Atkins wrote:
> I just thought of the one reason this proposal really bothers me.
> I knew there was something that wasn't sitting right and why I didn't
> think this would work.  It's not that I'm against making developers
> lives easier, but I want to make sure we don't lose something in kind.
>
> I like the ability to specify what changed in each and every file.

Sometimes, yes, especially if the commit fixes a couple of different issues 
across different (but interdependent) files. However, recently I've found 
this does generate duplication. There have been quite a few ChangeLog entries 
that are:
	* various :
or
	Change description
	* src/path/somefile :
	* src/foo/bar.c :

where one change affects all listed files almost equally. The FSF address 
change is the clearest example but it happens more often than that.

What I'd like is that the ChangeLog entries become "recommended" but not 
"mandatory".

Just getting rid of the warning about reverting any changes that lack a 
ChangeLog entry would be a welcome step.

Let those changes that need file-level detail go into the ChangeLog and those 
changes that really are one change across multiple files can be left to the 
svn commit messages, or an over-arching comment in NEWS, README or whichever 
file is the most suitable.

> When you leave the ChangeLog generation out of the developer's hands,
> you can't get this level of detail.  All you get is the overarching
> description.  You lose the ability to say what happened in each file.
> Maybe you don't document your changes enough to want that ability,
> but I do.

Usually I do, but not always.

I'm thinking of all those changes to the header files replacing private 
headers or removing unnecessary headers. The ChangeLog entries for a lot of 
those are just bloat - and because of the ChangeLog format of short lines, 
not using line wrapping, each section takes up a lot of lines.

> Personally I feel you should always run an "svn diff | more" prior
> to the commit to make sure you're only committing the change(s) you
> want.

(Can't think why, but my diff's tend to be so large I need to redirect it to a 
file!)
:-)

> Then C-x C-s the ChangeLog buffer, 
> M-w to copy the changelog entry, and then C-y once you get the svn commit

And in English for those who don't speak emacs ?!?!!
:-)

-- 

Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20051202/27b04ec8/attachment.bin


More information about the gnucash-devel mailing list