[ On Mon, October 24, 1994 at 17:38:28 (edt), mycroft@gnu.ai.mit.edu wrote: ]
> Subject: Re: sun-lamp CVS commits
>
> Why does it make sense to do that for send-pr and not for any of the
> other numerous programs in NetBSD?  I find it more than a bit silly to
> start suffixing programs in the NetBSD operating system with `.netbsd'
> or some such thing.

Because send-pr is different, since the version installed with NetBSD is
specifically customised for NetBSD.  *Everyone* else who supplies a
custom version of send-pr (so far as I've seen), has had the sense to
rename it to a unique name related to the project involved (eg.
"cvsbug").  How many send-pr's would we have otherwise?

Nothing else clashes so badly (i.e. so different in purpose).  Having an
O/S release clash like this with a likely local package is, in my
estimation, a bad thing.  Anyone using NetBSD in any sized organization
with their own internal support should be collecting their own PRs from
local users and only admins should be sending accurate PRs to NetBSD.

I don't care what send-pr is renamed to, just that it's different than
the default name used by the generic GNATS package and hopefully
somewhat meaningful to the purpose intended (i.e. reporting bugs to the
NetBSD group).

> Besides that, I expect that very few people will actually install GNATS
> It doesn't make sense to annoy or confuse (or, frankly, dumbfound; if I
> were Joe Random User, I'd wonder what drugs caused someone to rename it
> that way) the majority of users for the benefit of a handful of people
> who don't want to type `mv send-pr <whatever>'.

We alone are putting ~2,000 users on a NetBSD system, and I'd be moving
"send-pr" to somewhere such as /usr/sbin/sendbug and probably making it
executable by staff only, regardless of whether we were installing GNATS
locally, or not.  Otherwise we'll end up with a mess like what they're
getting in bug-gnu-emacs.

-- 
						Greg A. Woods

+1 416 443-1734			VE3TCP		robohack!woods
Planix, Inc. <woods@planix.com>; UniForum Canada <woods@uniforum.ca>