spec file changes: removing Release: and %changelog

[Colin Walters]

On Wed, 2008-03-05 at 13:34 -0500, Jesse Keating wrote:
> On Wed, 2008-03-05 at 13:28 -0500, Colin Walters wrote:
> > The overall idea is that the release number is determined by the "build
> > server", where "build server" can be either localhost (for make local),
> > or Koji (for Fedora).  So for local builds, you don't hit Koji to
> > determine a release - we just create one, and then increment it from
> > there.
> > 
> > We don't want to distribute locally-built RPMs as if they came from
> > Fedora, so giving them a .local disttag with a locally-determined
> > release is a good thing, I think.
> 
> But again, why is it by the build server?  You want to match the changes
> to the spec with a number usually, even if that number doesn't get
> built, or doesn't get successfully built.  This is why the kernel used
> to key the release from the cvs check in number.  Of course that ran
> afoul of branch collisions.

I see three options, in increasing complexity:

First, Koji could keep a mapping from its made-up Release integer to the
CVS commit tag.

Second, we could use some transformation of the CVS commit tag as the
Release.  

Third, we could switch to a revision control system with 

* Atomic commits
* A nice integer sequence mapping for commits on a branch

Subversion and Mercurial both have these properties; I'm not sure if git
has the second.