Theo Van Dinter writes:
> On Wed, Aug 30, 2006 at 09:54:05PM +0100, Justin Mason wrote:
> > http://use.perl.org/~petdance/journal/30809
> 
> Yeah, I can understand the POV.  Our changelog is generally written so that we
> know what's changed in a commit, and if we need more info, that's what the bug
> ticket reference is for -- and the Changes file lets people see those as well
> w/out needing SVN and such.
> 
> The URL above talking about expecting the changelog to talk about the
> human friendly "what's changed between revisions" list, which is something
> different. ;)

Yeah.

> There's really no reason we can't put the release announcement in the
> tarball I guess (we already keep the draft version for the last major
> (x.y.0) release in build/), except that we'd have to drop the hash values
> of course.

I was thinking about this.  However, it'd be much more useful if we
included multiple previous releases -- our release announcement
only includes the details of the single last release.

> However, on a slightly related topic, reading through the changelog
> recently, some of the entries are really kind of useless (not to pick
> on anyone specifically here):
> 
> ---------
> r437628
> trivial patch: remove annoying over-verbose warning already removed in trunk
> ---------
> 
> that doesn't actually tell us anything, so we'd need to look at the diff to
> find out what actually happened.
> 
> ---------
> r436735
> bug 5034: fix endless loop possible from bad input or network error
> ---------
> 
> I know this is M::SA::Client, but we'd have to look at the ticket or the diff.
> 
> ---------
> r434017
> remove temporary band-aid patch
> ---------
> 
> this really doesn't tell us anything, have to look at the diff.
> 
> ---------
> r433070
> oops... this should be -stable as well
> ---------
> 
> ditto.
> 
> 
> I tend to think commit logs don't need a fully detailed explanation, but being
> overly terse is not useful either.  Just a thought.

by the way, one interesting approach I used before, was to differentiate
between "noise" changes, that could be left out of
changelogs/announcements, and important changes, that needed to be
included -- basically, important changes had a prefix to flag them.

Then the changelog generation could ignore the crap changes that don't
need to appear in a changelog... like my 3 above ;)

--j.

Reply via email to