make force-tag gone

[Simo Sorce]

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 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.

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