[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: changelog format

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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]