Re: ChangeLog entry complexity

[Mike Frysinger <vapier at gentoo dot org>]

On Tuesday 02 April 2013 04:40:04 Florian Weimer wrote:
> On 03/25/2013 05:55 PM, Carlos O'Donell wrote:
> > Does anyone feel strongly that detailed change logs are limiting our
> > acceptance of new developers to the community?
> 
> GNU-style changelogs lead to under-documentation of changes in the
> version control history, and in the long run, they make it more
> difficult to work with the code base.
> 
> I'm not making this upâGNU policies encourage to duplicate information
> found in the version control history, and explicitly discourage
> providing context or a rationale:
> 
> <http://www.gnu.org/prep/standards/html_node/Change-Log-Concepts.html#Chang
> e-Log-Concepts>
> 
> The suggestion to add relevant information in comments is good, but it
> does not work at all when code is moved or deleted, and localized
> comments still do not address the bigger picture.

yes, i've felt this way for a long time with both glibc and sourceware.org 
trees.  if i'm browsing the history to try and figure out where a change was 
made and *why*, i'm pretty much f-ed.  the commit message the vast majority of 
the time is 1 line written like an e-mail subject: terse, dense, and often 
lacking in useful details.  the GNU ChangeLog adds absolutely nothing to this 
(assuming it was even committed at the same time).

my only recourse is to take that commit message and search the mailing lists 
and *hope* that i find it on one of the public ones related to the project.  
this works a good amount of the time (i'd say ~85%), but it's very time 
consuming.  what makes it even worse is mailman's archiving behavior of 
splitting across months.  the original message might be in one month, and 
follow up responses might happen in a different one, or even spread across a 
few.  this makes coordinating things even more of a pita.
-mike

Attachment: signature.asc
Description: This is a digitally signed message part.