Proposal: Better force-tag

[Adam Jackson]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20080915/c491fb8a/attachment.bin