On Mon, 2008-09-15 at 13:28 -0700, Toshio Kuratomi wrote: > Reversing the decision may be the right thing to do. To avoid seesawing It's not seesawing, it's re-examining a decision when more relevant information is presented. > decisions as one side and then another argues their case, I'd love to > hear a few words from the koji devs, though: > > 1) In what situations can things be broken with force-tags? (ie: is it > just when force tagging a successfully completed build? Are completed > failed builds okay? What happens if a retag occurs on an in-progress > build?) The only thing that can be "broken" is the ability to check the source back out via the tag and have it match what went into koji. Once koji has done the initial checkout, it's done with CVS for that build. Nothing later in the build task requires hitting CVS, so changing the tag for an inflight build does not harm the current build. If somebody requests a task be resubmitted, there is a chance that the content that comes out of CVS will be different than the first time. Then again, the content in the buildroots can be different as well. Really nothing in the way we /currently/ use Koji and CVS requires that the tags not be forced. We just can't add any functionality to our infrastructure that would depend on it until we close this loop. > > 2) What breakage occurs? (ie: the current discussion seems to be that > only recreating an SRPM for GPL compliance is broken. What about > requeue and other koji functions?) I tried to cover that above. > > 3) Is there a plan for fixing things so developers don't need to do > retags? Timeframe? Is it acceptable to leave these commands in until then? It was not really a priority to fix, there were other things being worked on. We can certainly make this a priority, although it's really more of a Make/CVS issue than a Koji issue. > I feel like FESCo is in the unenviable position of mediating between > tool developers who say the tool doesn't operate the way people are > using it but haven't given enough details of what the problem is and > package maintainers who want to do something potentially problematic > because of other deficiencies in the tool. More communication between > the two endpoints is desirable here. > -- Jesse Keating RHCE (http://jkeating.livejournal.com) Fedora Project (http://fedoraproject.org/wiki/JesseKeating) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) 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
