On Tue, 2008-09-09 at 16:57 -0700, Toshio Kuratomi wrote: > 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. If koji does tag the build with the timestamp as the first thing then it doesn't really matter. It will re-tag the same with n-v-r once the build is successfully completed. > > 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. I think so, I don't believe people should be able to change tags once a build successfully completed, and if some people need "non-build-tags" then all we need to do is probably just reserve a tag namespace for koji (the official one) and let user add other tags as they see fit, for their own need. > 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 Not sure we need the username and n-v-r here, but I am not too concerned about that, this in general sound like the process I had in mind. > * Note: The timestamp in the tag doesn't need coordination between > machines in this scenario, it is only used to make the tag unique. Exactly, that was my idea too. Simo. -- Simo Sorce * Red Hat, Inc * New York -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
