Re: (forw) per-arch __P removal done, please test
review.



David O'Brien wrote:
> I *ALREADY* told you 30 minutes ago on IRC that I have alread done Alpha.

Wow, and people think using Perforce to communicate between
developers is responsible for creating a small clique of
people, limiting who can participate in the process...


> PLEASE no one commit Alfred's patch. It will conflict badly with my
> effort here -- which is even being compiled tested.

Actually, shouldn't it be identical?

If it's going to be done, then Just Do It. It's not like it
takes a PhD to remove __P(), or one to understand code where
it's at, for that matter. It just doesn't seem that big a
deal... it's a lot of unpleasent grunt work. Which seems to
be designed to lower the intelligence barrier and permit people
whose ability to understand code magically shuts down when they
see "__P()" to contribute their otherwise insightful and high
quality code to the project.

Alfred has made a name for himself by tackling unpleasent
grunt work as it comes up; so freaking what? The:

> You just want to get your name in lights don't you??

comment is really unwarranted.

At a previous company, a manager got a bug up his butt that
getting rid of LINT warnings using FlexiLint would magically
make the code better, even though some of the casts that had
to be there to make that happen actually hid important
semantic conversions which constrained future use. Making
the code LINT cleanly hid these semantics, planting land
mines for future programmers.


Rather than shut down engineering for a week while people
went off on this futile and (be honest) assinine exercise,
I and one other engineer took it upon ourselves to spend a
little over 4 hours "fixing" the code so that it LINT'ed
cleanly, after it was announced that the company would take
time out to "fix the LINT bugs".
r>
Did we get some public kudos over it? Yes. But that was
not the intent of the exercise. The intent of the exercise
was to get the LINT-harpies off the backs of the engineers
so that the make-work of passing some idiotic tool's idea
of what constitutes good taste didn't impact the developement
schedule. The public kudos in fact detracted from the point
we were trying to make by somehow legitimizing the exercise;
we didn't care: we hadn't lost a week to all of engineering
diddling themselves.


Now I personally asked the __P() question I did because I
don't really track -current closely. It moves too fast,
often back-tracking, and it's so significantly different
from -stable that there is just no way to reasonably develope
code for both. And people wonder why most people are not
looking at -current, and why I and others feel that some
"Developer's Preview CDROM" isn't going to fix the problem.


If it had been OK to do the work in -stable, I would have
done exactly what Alfred did here, just to shoot the stupid
discussion in the head so that it didn't distract from real
work, and despite the fact that it puts the FSF more firmly
in our pants. It would have also been worth it to me to be
able to minimize the deltas between -stable and -current, so
that there was some chance in hell of work on one being
relevent to the other.

PS: If you can't tell, I think this whole __P() thing is
a critically stupid waste of time.

-- Terry

To Unsubscribe: send mail to majordomo@xxxxxxxxxxx
with "unsubscribe freebsd-alpha" in the body of the message





Privacy