Re: Proposal: Better force-tag

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux