Quoting Paul Wouters (2012-05-21 02:02:23)
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
OK. Many of us agree that rpm changelogs could be generated from git.
Now there are multiple approaches. As was said before Mageia/Mandriva
have been doing it for a while. However I dislike approach of specific
commit messages that will "remove" commit from changelog. Instead my
proposal (that I am willing to work on with relengs/infra):
* If there is a changelog in spec we assume packager keeps its
changelog manually so we leave it be. This gives everyone time to
adjust as they see fit.
* By default add every git commit message except merges to rpm changelog
on koji. I.e. no action from packager necessary
* If a git commit is tagged in a specific way, omit from rpm changelog.
What I mean by "tagged" is a git tag, in form of let's say
"silentXXX". Where XXX has to be unique, but that can be figured out by
fedpkg easily.
The way I see it, this could be relatively painless migration where
packagers would not have to change their workflows immediately.
Does anyone have any strong opinions against this approach? Note that I
am not asking you to express your dislike for git changelog generation.
You will have time for that later for sure
--
Stanislav Ochotnicky <sochotnicky(a)redhat.com>
Software Engineer - Base Operating Systems Brno
PGP: 7B087241
Red Hat Inc.
http://cz.redhat.com