Subject: My take on the send-pr issue
To: None <email@example.com>
From: J.T. Conklin <firstname.lastname@example.org>
Date: 10/24/1994 20:49:29
Every so often, we are asked by someone to make some change to the way we
distribute a piece of software that has been integrated into NetBSD.
Most often the complaints are about gcc.
Even though I don't remember acting on any of the requests so far, I don't
automatically discount them. Most of the time there is a reason for why
we do things the way we do. But if we are doing something someway just
because that has always been the way it has been done, I think that the
request should receive some consideration.
For example, almost every time someone asks us to drop in a new gcc
distribution into NetBSD, I respond with a boilerplate message explaining
why we have decided to integrate gcc into NetBSD with BSD-style makefiles.
There is a reason behind that decision, and I hope I can explain the
reasoning behind installing send-pr as send-pr, and why it should be
installed in a normal user's path.
First of all, I think most NetBSD developers honestly want to see bug
reports. So it should be as easy as possible for any user to submit
them. It doesn't take that much effort to close duplicate or bogus
problem reports, so why make it difficult for ordinary users to submit
them? Hiding the problem report submittion program runs counter to that
The reason that send-pr is installed as send-pr is that there doesn't seem
to be a good reason to do otherwise. We'd have to change the man pages,
texinfo documentation, etc.; and maintain them in parallel with the real
send-pr (even with CVS, this isn't a trivial task) for negligable gains.
Besides, send-pr was designed to support multiple "support sites".
Granted, such support isn't perfect, but it does seem to work. I have
emailed the PRMS maintainers with some suggestions to make it better, and
I hope that some of them will be integrated as part of the upcoming GNATS