make force-tag gone

[Jeff Spaleta]

On Wed, Sep 10, 2008 at 4:05 AM, Christoph Wickert
<christoph.wickert at googlemail.com> wrote:
> Am Dienstag, den 09.09.2008, 09:28 -0800 schrieb Jeff Spaleta:
>> On Tue, Sep 9, 2008 at 8:45 AM, Debarshi Ray <debarshi.ray at gmail.com> wrote:
>> > I have happily used 'TAG_OPTS=-F make tag' [1] on the rare occasions
>> > that I needed force-tag. I might try to use local hacks to get around
>> > it if people decided to try and block 'TAG_OPTS=-F make tag'. :-)
>>
>> We will ultimately need to also disable TAG_OPTS=-F as well
>
> -1


You are -1 to my statement? You find my statement factually incorrect?
I'm really sick of the +1 and -1... this isn't a vote..this is a discussion.

Here I'll reproduce my entire quote verbatim again:
"We will ultimately need to also disable TAG_OPTS=-F as well if we want
to make cvs tags immutable references that we can rely on to generate
corresponding source on demand."

IF we want to rely on tags for anything that has a legal
implication... then they must be immutable...and even TAG_OPTS=-F must
be disabled if it threatens the reliability of the tags. There's no
in-between. If we are going to rely on cvs tags then they must be
immutable.  Education and the honor system is not enough. If we are
going to rely on them for any number of auditing reasons they must
become immutable.

The statement has absolutely nothing to do with the utility of
TAG_OPTS=-F in dealing with trivial changes. I'm sure both TAG_OPTS=-F
and force tagging are useful to someone. Such utility is not an
argument against immutability for the sake of auditability.

Nor does my statement assume that cvs tags are the best way to create
the source audit trail. But if we are going to attempt to rely on cvs
tags... then they must be immutable. If TAG_OPTS=-F is a way to cause
damages that immutability...it will have to be disabled.

With force tagging off but TAG_OPTS=-F still available, its not clear
to me what additional assurances on tag fidelity we have actually
gained in the current situation. Half-measures, are no measures.


-jef
>
> There are situations where "TAG_OPTS=-F" is really handy and I stumbled
> over one last night while doing a review: On the topic of ExcludeArch
> the review guidelines state:
>
>> Each architecture listed in ExcludeArch needs to have a bug filed in
>> bugzilla, describing the reason that the package does not
>> compile/build/work on that architecture. The bug number should then be
>> placed in a comment, next to the corresponding ExcludeArch line. New
>> packages will not have bugzilla entries during the review process, so
>> they should put this description in the comment until the package is
>> approved, then file the bugzilla entry, and replace the long
>> explanation with the bug number.
>
> When I approve a package I expect this very special package (NVR) to be
> imported into CVS. But for packages with ExcludeArch it means that the
> review requester will have to
>     1. file a bug after CVS admin procedure is done and the bugzilla
>        component was created,
>     2. import the package (where it is automatically tagged),
>     3. add the bug # to the ExcludeArch statement in the spec and
>     4. then the bump the release only for a trivial change in the spec
>        that
>              * does not affect the functionality of the package nor of
>                the spec in any way
>              * is not visible to users at all and
>              * is not caused by the packagers inattention
>
> You see: There are situations where forcing a tag really makes sense.
> Instead of banning "TAG_OPTS=-F" we should better educate our packagers
> to not abuse it (accidentally). make tag should check if the same NVR
> has already been build successfully in koji, but as long as this is not
> implemented we should stick with forcing tags.
>
> Regards,
> Christoph
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>