make force-tag gone

Toshio Kuratomi a.badger at gmail.com
Tue Sep 9 23:57:43 UTC 2008


Simo Sorce wrote:
> On Tue, 2008-09-09 at 13:24 -0700, Toshio Kuratomi wrote:
>> Simo Sorce wrote:
>>> On Tue, 2008-09-09 at 08:12 -0800, Jeff Spaleta wrote:
>>>> On Tue, Sep 9, 2008 at 8:03 AM, Denis Leroy <denis at poolshark.org> 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.
>>>> I believe he misspoke.  You are of course free to make 300 small
>>>> separate specfile changes between each build attempt.
>>>>
>>>> There is a desire to move to a point where we can be reasonably sure
>>>> that a cvs tag corresponds to a specific build.  Since we have no way
>>>> of making only tags corresponding to successfully built packages
>>>> immutable, all tags must be immutable.
>>>> Find me a way to mark only the subset of cvs tags which correspond to
>>>> a successful koji build as immutable.
>>> If this is the aim, then koji should be the one to tag the CVS after a
>>> build is successful.
>> Question 1: Does this still fall under the all or nothing prevention of
>> moving tags?  I don't know CVS well enough to know if there's a
>> fullblown hook that can be run to determine that "all tags prefixed with
>> koji-* are immutable".  If so, that is a way to achieve this and was
>> proposed by Jesse several months ago.
> 
> I like this proposal.
> 
>>> It doesn't make sense to tag an unsuccessful build,a nd it is an
>>> unnecessary burden on developers.
>>>
>> Actually... tagging an unsuccessful build is useful.  How else do you
>> take a look at what caused a particular build to fail?  I think having
>> multiple immutable tags for the same NVR would be preferable.
> 
> I didn't say adding tags should be prevented, but I find it unnecessary
> to force people to run make tag before make build, let koji tag a build
> if it is successful, and let people ad tags if they need, just not force
> people to tag when koji can do it with knowledge that that is a good
> build.
> and you might also decide to add tags for broken builds if you please by
> appending a broken build suffix (timestamp) so that you can keep using
> the same n-v-r until you get a successful build.
> 
I've thought up a reason for having tags be done by the build submitter.
   Race conditions.  Say koji is having a really busy day.  I cvs
commit.  Then make build. The request goes to koji which allocates a job
to handle the request.  Even if the first part of the job is a simple
prep that figures out the versions of files in cvs to work with, there's
a chance that someone else will cvs commit before that koji job
finishes.  Even if you take care of that, there's still the chance of
clock skew between the builder and cvs server.

> Actually adding an automatic koji-<package>-<timestamp> tag
> automatically when running 'make build' is not a bad idea, is it ?
> 
I like automatic.  I'm wondering if we just get rid of the make tag step
if we get rid of the need people see to move tags.

For instance:

make build => Creates a new unique, immutable tag like
koji-username-package-nvr-timestamp and submits to koji
koji processes the tag as normal and adds the information to its database.
  If failure
  packager cvs add's and cvs commits a missing patch file.
  make build => Creates a new unique tag with the same username,
package, and nvr but a new timestamp.
  repeat as necessary

* Note: The timestamp in the tag doesn't need coordination between
machines in this scenario, it is only used to make the tag unique.

* Note: I don't know if koji has some understanding of what the tag
looks like although I don't see why it should.

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20080909/5b1c6c17/attachment.sig>


More information about the fedora-devel-list mailing list