On Thu, 2008-09-11 at 14:47 -0700, Toshio Kuratomi wrote: > This specific implementation would be a bad thing. Instead of having a > nice, SCM abstract method of communicating to koji what to build from > (the tag) you'd be resorting to CVS specific knowledge. I don't necessarily disagree, however that's something to figure out /before/ you remove force-tag capabilities. Not after. > > > Instead, we're forcing all of our users to change how they work because > > some people feel uncomfortable about something WE'RE NOT EVEN RELYING > > UPON!! We don't rely upon anything to go backwards at this time. > > Nothing. I have no objections to finding a way to make absolutely > > certain that what koji builds from is immutable and can be pulled out of > > source control. No objections at all. I highly object to forcing our > > users to come up with this for us, because they're so pissed off that > > we've removed tag moving. > > > > Simply put, figure out a way to meet the immutable requirements first, > > before taking away the ability to move tags forward. Don't remove that > > ability, and then sometime in the indeterminate future fix the immutable > > problem. > > So I see a certain bit of mismatch here between what koji is made to do > and what people want to do. It's also one of the contributing reasons > we aren't yet building EPEL in koji: > > Reproducibility of Builds > > In order for this to hold true, you have to consider the input streams > (cvs, lookaside cache, and download repositories) as part of koji. If > we could upload new files to the lookaside cache locations or > arbitrarily change what's in the SCM or change the packages in the > repository without koji knowing then koji loses the ability to reprodce > builds. > > Note that I think the particular implementation of Makefile.common and > koji forces us into a no-win situation in this. On the one hand, tags > that go into the buildsystem must be immutable in order for the > reproducibility of builds to be assured. On the other hand, the tag is > tied to the version and release of the package in such a way that it's > impossible to submit a new build without bumping the version in the spec > file even when no packages were created in the previous run. We need to > decouple these. I think it'll require changes to Makefile.common (to > write the tags), CVSROOT/admin/tagcheck (to check for immutability of > specific tags), and koji (to check that the Version and Release in the > spec file isn't currently a building or built package). That way has been discussed as well, and is being worked on by Mike M. and Mike B. My big point here though is that work should be done, tested, and put in place, before any act of removing force-tag was done. We're not just talking about the Make alias(es) for it, because if you're really serious about wanting to prevent tag moves, you have to block at at the CVS server side. It's an arms race. This is a clear case where it must first continue to be usable by the users before you fix the underlying problem. First, do no harm. We should have learned this lesson after the Core/Extras merge and various fallouts therein. -- 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
