Re: Proposal: Better force-tag

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

 



On Mon, 2008-09-15 at 13:51 -0600, Kevin Fenzi wrote:
> On Mon, 15 Sep 2008 14:15:15 -0400
> dledford@xxxxxxxxxx (Doug Ledford) wrote:
> > Look guys, maybe what we have here is a case of mis-communication.
> 
> I think this entire thing has been a lot of mis-communication. 
> 
> First of all I didn't think this was that big a deal. 
> I have used 'make force-tag' and/or 'TAG_OPTS=-F make tag' a few times,
> but it was very few and far between. I guess possibly because I don't
> have packages that have tons of changes always happening. 
> (yes, I also mockbuild locally my packages before checking in changes
> too, which I realize is not practical for everyone). 

It varies from person to person and package to package.  I locally build
almost all of my packages, but I have a few that are ppc/ppc64 only and
I have no means of building them.  So, they get their testing done in
the build system.  On those packages, I make judicious use of force-tag.
In addition, the kernel is a good example of one that I use force-tag on
because it also may break on arches other than your own (the kernel is a
bit special in that is has so much arch specific code that the chances
of another arch breaking are quite high for certain types of changes).
I *could* do an srpm build to test ppc/ppc64 kernel builds, but it takes
30 minutes for a kernel srpm to upload to the build system from here
(admittedly, I do this on my rhel kernel builds, I haven't been messing
with Fedora kernels, but the point is valid regardless), so I commit,
tag, build, fix, force-tag, build, fix, etc.

> I don't think you are wrong, but I think this entire thing has been a
> miscommunication of the importantance of this change. I personally
> didn't think it was a big deal, it seems I was wrong. 

There are two aspects to this.

1)  It's a change to solve a problem.  The problem is, it didn't solve
the problem.  That made the action analogous to security by obscurity
type actions.

2) When it doesn't solve the problem, and it negatively impacts people's
work flow, and you go ahead and do it anyway, then it feels like the
majority of us that use it responsibly are being punished for the
actions of a few.  In fact, I would liken it to all the DRM placed on
songs or videos: it doesn't stop the criminals from doing what they are
going to do, but it makes the lives of honest people more difficult.

I'm going to go out on a limb and say that the reason so many people
have objected to the change is because we don't give FESCo the right to
make our lives more difficult without cause.  Due to #1 and #2, that's
what they did.  Don't do that and we'll get along *much* better ;-)

Anyway, I'll withdraw my statement that I won't ever vote for you guys.
It doesn't sound like people here are on a power trip, instead it feels
a bit more like an unfortunate rookie mistake ;-)

-- 
Doug Ledford <dledford@xxxxxxxxxx>
              GPG KeyID: CFBFF194
              http://people.redhat.com/dledford

Infiniband specific RPMs available at
              http://people.redhat.com/dledford/Infiniband

Attachment: signature.asc
Description: This is a digitally signed message part

-- 
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux