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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
