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. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
