changelog format

[Adam Williamson]

On Mon, 2009-04-20 at 18:16 -0700, Jesse Keating wrote:
> On Mon, 2009-04-20 at 16:18 -0700, Adam Williamson wrote:
> > so you manually write the one with extra bumph that could easily be
> > automatically generated, and then use that to produce the one which
> > *doesn't* have extra bumph that could easily be automatically
> > generated? :)
> 
> I'm not sure I follow.  CVS sort of lends itself to doing a days worth
> of changes in one commit, so it's work work work, documenting work as
> you go in the .spec file  (although often it's just "new upstream
> release" or "patch for $foo", then when you're ready to make it happen
> it's "make clog && cvs commit -F clog && make tag build"
> 
> Now if we were using a scm that was more geared toward commit as you go,
> we might consider something different, but even then what you want to
> expose to users isn't necessarily the same thing you want to document
> when doing SCM commits.  Here is where git is neat with the shortlog,
> where you oneline your change, but then can expand upon it in another
> paragraph that will be seen when looking at the git log, but won't be
> seen if you do a simple short log (like say for stuffing in a .spec
> file).

OK, I see what you're driving at now. But you missed one point I wrote
on the issue of where you want the two to be different - you can just
implement a keyword for commit messages which causes it not to go into
the RPM changelog, viz:

cvs commit -m "this commit message will go into the RPM changelog"
cvs commit -m "SILENT: but this one won't!"

pretty simple.

However, now I get your point, I agree that the issue of switching SCMs
would be more significant and an appropriate place to look at this issue
too. CVS is pretty creaky these days.

FWIW, when I was working on packages at That Other Place, I would work
work work all day and then commit too, but with a commit message that
looked like this:

- one change
- another change
- yet another change
- SILENT: a trivial change i don't want to go in the RPM changelog

and that all got parsed correctly into the RPM changelog, in the way
you'd expect it to.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net