Stop the git abuse

[Simo Sorce]

On Mon, 2012-05-21 at 14:21 +0200, Emanuel Rietveld wrote:
> On 05/21/2012 01:56 PM, Ralf Corsepius wrote:
> > Technically, the major difference is git recording each and every
> > detail, which an rpm's user hardly is interested in. The latter audience
> > is not interested in seeing these details, they are interesting in
> > "summaries".
> >
> > E.g. they are not interested in seeing
> > ........ ABC-3
> > ... Fix memory leak (PR XYZ).
> > ... merge from HEAD.
> > ... merge cleanup.
> > ... fix typo in previous commit.
> > ... fix yet another typo.
> > ........ ABC-2
> > ... Upstream update.
> >
> > They are interested in reading
> > ........ ABC-3
> > ... Fix memory leak (PR XYZ).
> > ........ ABC-2
> > ... Upstream update.
> >
> > Ralf
> 
> Could one of these help?
> 
> A) Generate RPM changelog automatically from git, but only process 
> commit messages with some token, like "%changelog"

The problem with this is that you can never fix the old changelogs if
you notice typos or any other problem with them, so you'll end up trying
to invent ways to do it by adding even more tags, that road is a bad one
to take.

> B) Have package maintainers use git commit editing tools to make a 
> 'clean history' - squash typo commits, for example, and replace merge 
> messages with something more informative.

Except we do not allow to rewrite history and push -f so you will never
be able to squash everything.

Also due to the love for merges taking a changelog from git commit
message would be messy.

However, using a separate file (or even the spec file) that we can
automatically append to using fedpkg and sourcing chngelogs from the
latest git commits and then can be manually edited to clean that up
before commit/push would seem like a good idea.

In normal case it will help the maintainer by speeding up the time
needed to write down changelog entries.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York