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 > conflicts. > > 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 -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty nils@xxxxxxxxxx nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel