make force-tag gone

Toshio Kuratomi a.badger at gmail.com
Tue Sep 9 20:24:07 UTC 2008


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.

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

-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/d0f489be/attachment.sig>


More information about the fedora-devel-list mailing list