[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: make force-tag gone

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


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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]