My take on the send-pr issue

[jconklin%netcom.com@localhost (J.T. Conklin)]

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 
goal.  

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
release. 

        --jtc