On Mon, 2008-09-15 at 13:51 -0600, Kevin Fenzi wrote: > 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's not that it's not practical, it's that it's not sufficient. I regularly trip up on architecture differences. Granted, X is intrinsically hardware-dependent in a way that (say) coreutils isn't, but anyone who's ever had to deal with a multilib bug has probably hit this too; it's just too much to keep in your head, so don't bother, let the build system sort it out for you. I think the major objection here is that the solution didn't match the problem, even to a first degree. First you remove force-tag, then someone notices TAG_OPTS so you have to remove that, then they notice that cvs tag still works so you have to go lock it down server-side. We're typically willing to accept workflow changes if they are well-deployed and achieve a worthwhile goal. This, manifestly, did not. Now, that it was done without announcement, and apparently without even cursory investigation into the solution space, is the sort of thing that makes people go all ranty and arm-wavey. Personally I try not to get too worked up about communication problems, since afaict it's just the reality of dealing with nerds on the internet. But that's not to say we don't have lessons to learn. - ajax
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
