Time has come to stop with /usr/local path pollution!
Ken Murchison
ken at oceana.com
Sat Sep 28 08:44:52 EDT 2002
Quoting Andrew Diederich <andrew at NETdelivery.com>:
> 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.
Its seems that people are missing a very important point here. Cyrus was
developed for internal use at CMU. CMU has been kind enough to allow the
source code to be distributed for use by anybody, commercial or otherwise.
Some may argue that CMU has a responsibility to fix all bugs, write good
documentation, hand-hold ignorant/illiterate admins, make coffee, and clean
windows. In most cases, they do all of the above, and more.
I wish people would keep this in mind, when they claim that the build process
is broken. It is broken for _you_, because I can assure you that it built for
the intended user (CMU). The developers first responsibilty is to their
employers, not to a small, whiny part of the user community with an edge-case
problem.
If people spend the same amount of time trying to fix the problem instead of
bitching about it, this would've been a dead issue a long time ago. It don't
think that the "squeaky wheel gets the grease" principal is necessarily going
to work.
The next time somebody is frustrated by the software and wants to rant about
how much of their time the developers wasted, take a step back and remember how
much time and money they actually _saved_ you.
Another $.02
> -----Original Message-----
> From: Rob Siemborski [mailto:rjs3 at andrew.cmu.edu]
>
> 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
>
>
>
--
Kenneth Murchison Oceana Matrix Ltd.
Software Engineer 21 Princeton Place
716-662-8973 x26 Orchard Park, NY 14127
--PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp
More information about the Info-cyrus
mailing list