Date: Wed, 20 Mar 2002 14:12:42 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: obrien@freebsd.org Cc: alpha@freebsd.org, Alfred Perlstein <bright@mu.org> Subject: Re: (forw) per-arch __P removal done, please test review. Message-ID: <3C99095A.8C598A76@mindspring.com> References: <20020320181508.GG455@elvis.mu.org> <20020320101950.A65314@dragon.nuxi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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". 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@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C99095A.8C598A76>