I'd just ask that if a known bug isn't going to be fixed, it needs to be documented and put upfront, big and large, where folks will see it. Shutting off compiler warnings with gcc 3.2 is an example. It broke compile, but folks were talking about it on the list.
Many of the developers, and people on this list, know about the problem, but people who just download the software, read the docs, and try to install it will get burned otherwise. Then they'll curse the crappy software, and they'll be right. There are three things to do when a bug is found. 1) fix it, 2) document the bug and the workaround, or 3) hope people don't find it again. #3 is terribly expensive in support costs, like this string of emails. -- Andrew Diederich -----Original Message----- From: Rob Siemborski [mailto:[EMAIL PROTECTED]] On Fri, 27 Sep 2002, Michael Newlyn Blake wrote: > However it does seem that when explicit paths are called for certain > componants they should be placed in line before the assumed system paths. > That is to say, if you want to build and link against a libfoo in > /snert/myjunk/foo-8.3.4 then this should be placed in the relevant paths > before the include and lib dirs in /usr or /usr/local that are added > automatically. I agree 100% that the paths should be honored. However, since it works for most people, and testing is pretty annoying (as ken stated), I'm not terribly eager to spend my time doing it, when I could be working on performance or feature improvements elsewhere in the code. If there was a patch provided that I could look at, approve, and apply, I'd be willing to do so. This is much less the case if I'm going to have to read a bug report hidden inside of a rant that seems to assume that the developers of Cyrus are part of a consipracy against all system administrators everywhere. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
