%changelog not in descending chronological order

[Michael Shigorin]

On Tue, Jul 17, 2012 at 02:17:59AM +0200, Kacper Kornet wrote:
> > > But that would be not 'totally unordered'.
> > > GIT history is just not linear
> > It's the different history: take %changelog as NEWS
> > and commit messages as CHANGELOG.  The latter is for
> > developers while the former is for users (sysadmins).

(at least that's my take at the problem, of course)

> > And for a given package there's sense to make sure
> > its git history *is* linear.
> > See e.g. http://git.altlinux.org/gears/r/rpm.git
> Could you elaborate a little more how do you do it?

I write my %changelogs by hand since that allows me the luxury
of proper commits with explanations regarding developer side
(like if I was documenting things for myself reading it again
a year or two later), *and* yet allows me the luxury of reading
terse enough changelogs via rpm -q --lastchange :)

> I see that changelog entries are still present in spec files,

Yes; that's both good and bad, not sure if openSUSE or PLD
approach wins for me (but it's only a personal opinion!).
Generated data tend to be less useful due to lower SNR.

There's a gear-commit(1) utility for doing the opposite,
generating commit messages from %changelog records:
http://docs.altlinux.org/manpages/gear-commit.1.html

> and they are generated from commitlogs of tagged commits.

Might be but not enforced to.

> But how does these commitlogs are generated. Are they some
> short of condensed 'git log' from the last tag?

There's gear-changelog(1) utility developed for the storage
format born at ALT some six or seven years ago:
http://docs.altlinux.org/manpages/gear-changelog.1.html
http://docs.altlinux.org/manpages/gear-changelog-rules.5.html
http://www.altlinux.org/Gear/changelog [ru]

Maybe it serves as a good starting point for PLD's one.

Just in case, server side has girar- prefix:
http://git.altlinux.org/people/ldv/packages/?s=girar

> And how to you force that the tagged commits are in
> chronological order?

The next "buildable" tag has to inherit from the previous
successfully built tag for the successfully built new package
to be allowed through to the repository.  There's considerable
work by Alexey Tourbin in place regarding the repository
consistency, I can give a link to a whitepaper in Russian
(proshu pana).

DISCLAIMER: there are some troubles with the (almost) free-form
git repos that gear supports for package generation; if interested,
I can try to sum these up.  In short, getting a repo into a state
when no sane Patch: series could be extracted and stored in srpm
is pretty easy, it's enough to be lazy and fix things in-place...
(ALT used to be a meaningful source of patches but this got hit
pretty heavily by megapatches or even %name-%version-%release.tar
files incorporating all the upstream code and patches/commits in
nearby git branches).  And that's a problem.

By the way, *thank you* PLD folks for your nice specs with
predictable URLs as well as for nice standalone patches.

-- 
 ---- WBR, Michael Shigorin <mike at altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/