Adam Williamson wrote:
> That's pretty much the exact *opposite* of what I put in the changelog,
> FWIW. For me, that stuff goes in the git commit message (and even then
> I don't really break it down in that much detail, because the tools
> make it easy to see *what* changed, the thing the commit message has to
> fill in is *why*). What goes in the package changelog is changes that
> actually make a concrete difference to a *user* of the package. They
> don't give a damn about the BuildRequires changing.
Well, the user-centric stuff belongs in the Bodhi update notes first of all.
To me, the specfile %changelog is somewhere inbetween, it contains things
like added BuildRequires (which I would not put into the Bodhi notes unless
it enables some user-visible new feature), it does not contain upstream
changes (or at most a one-line summary when it matters, e.g. "adds support
for Python 3"; anything beyond that is only for the Bodhi notes), but it
does not contain things like "fix a typo in the date of the previous
changelog entry", those are things I address with a git commit without
touching %changelog.
So, to me:
* git commit notes: full detail of packaging-level changes including fixes
for screwups in the preceding commits, higher error rate
because I cannot fix them in followup commits (I would
have to force-push, which is not allowed in Fedora
dist-git, to do that),
* specfile %changelog: cleaned-up version of packaging-level changes that I
am comfortable with letting the users read,
* Bodhi update notes: user-centric write-up of the changes, including
(relevant) upstream changes, that actually matter to
the user – I added "relevant" because if I copy&paste
a list of upstream changes, I actually remove the
things that are clearly not relevant on Fedora (e.g.,
because they are specific to some other operating
system).
Kevin Kofler
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
