On Tue, 2008-09-09 at 09:46 -0700, Jesse Keating wrote: > On Tue, 2008-09-09 at 18:03 +0200, Denis Leroy wrote: > > > > There's no logic here. You're not forcing people to tag after every CVS > > check-in, as far as I know. If a release 'n' fails to build (for > > example, because you forgot to check-in a patch), it makes zero sense to > > bump to n+1, because release 'n' never *existed* in the first place, > > since it was never built. That has zero impact over auditing. Spec file > > auditing is done through CVS. > > The audit part is something of a red herring. The GPL compliance part > is what is bothersome. If we want to save archive space by relying on > re-generating srpms of shipped binaries on demand, we need to ensure > that CVS tags don't change over time. For better or worse, we build > from CVS tags, so to get the source that matched the build, we have to > checkout via CVS tags. If those tags can change over time, the trust > level is gone. That's why there is a push to make the tags immutable, > or at least the successfully built tags immutable. > > Personally I just want to move off of CVS and off of building from tags, > and instead build from something inherently immutable, like the shasum > of the repo at a given time. > > MikeB said that he'd look into some CVS/make changes that would allow > checking koji for an on going or successful build of a tag/n-v-r before > allowing a force-tag. This would allow folks to force-tag before having > a successful build, but would not allow you to force the tag after a > successful build, or while a build is still going with that n-v-r. > > I think this approach, while it may slow down force-tags and prevent > force-tags during any koji outage, will give us the best of both worlds. +1 Simo. -- Simo Sorce * Red Hat, Inc * New York -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
