changelog format

[Jesse Keating]

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).

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090420/69156cb5/attachment.sig>