changelog in spec file, was Re: Stop the git abuse
nils at redhat.com
Thu May 31 09:51:37 UTC 2012
On Sun, 2012-05-20 at 20:02 -0400, Paul Wouters wrote:
> On Fri, 18 May 2012, Richard W.M. Jones wrote:
> > On Fri, May 18, 2012 at 07:07:56PM +0200, Remi Collet wrote:
> >> And definitvely, for me, (and probably only for me), git is really
> >> not a good tool for spec maintenance.
> > Not duplicating the changelog would help. There's little reason to
> > have a changelog in git which is then manually copied into %changelog.
> Agreed. changelog and version field conflicts are 90% of my cherry-pick
> I would be in favour of no longer maintaining a changelog in the spec file
Maybe I'm a bit late, but with all the schemes I've seen in this
(sub-)thread that generate %changelog from SCM commits, how would I go
about amending old changelog entries? Also I don't see how NVR for
changelog entries can be safely determined from the SCM commits -- often
I build from the commit in which I bump the release, but sometimes I
make mistakes which I then need to fix and the build is from 3 commits
later -- the the guidelines are quite adamant that you either need to
merge all changelog entries leading to a build into one, or that each
entry is labeled correctly.
In my opinion, the cleaning out of mass-rebuild etc. entries for other
branches is a bit of optimization in the wrong place -- who looks at the
RPM changelog and can't put these things into proper perspective? The
changes relevant for end users are what you write when you submit an
update to bodhi.
Nils Philippsen "Those who would give up Essential Liberty to purchase
Red Hat a little Temporary Safety, deserve neither Liberty
nils at redhat.com nor Safety." -- Benjamin Franklin, 1759
PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011
More information about the devel