make force-tag gone

[Jesse Keating]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20080909/511d348f/attachment.sig>