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.