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. -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
