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@xxxxxxxxxxxxx> 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
Attachment:
signature.asc
Description: OpenPGP digital signature
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
