Jonathan Stone writes:
> There's one very important principle at stake here that I haven't
> seen explicitly addressed.  That principle is that ``third-party''
> software in the NetBSD tree should be kept as close as possible
> to the third party's original version -- at least, if the third
> party is actually maintaining that software.   Doing anything else
> diverts a valuable and limited resource to maintaining what, for
> want of a better term and without meaning to sound perjorative,
> I would call "local hacks".

You know, funny about that.  I've been meaning to bring this up to "core" for
a while now.

For example, we have "tcpdump" in our tree.  The current version that's
integrated is 3.0; the current version from LBL is 3.0.4.  But that aside, I
have some nifty patches from a guy at DEC whose name has been lost to history
(mainly to print-llc.c; NOT Jeff Mogul btw).  The main point of these patches
is to do a little more with Ethernet packets encapsulated inside IEEE 802.3
packets, most important of which is discombobulation of AppleTalk/EtherTalk
packets.

The "tcpdump" man page has always stated that stock "tcpdump" only works on
KIP AppleTalk packets (i.e., AppleTalk DDP encapsulated inside UDP), because
that's all they had at LBL on their networks:

       Apple EtherTalk DDP packets could be dumped as  easily  as
       KIP  DDP  packets but aren't.  Even if we were inclined to
       do anything to promote the use of EtherTalk  (we  aren't),
       LBL doesn't allow EtherTalk on any of its networks so we'd
       would have no way of testing this code.

For those of us in a different "real" world, this isn't the case.  Thus the
patches.  But since the LBL folks aren't likely to need them (or care),
they're not likely to make it back into the "mainline" distribution.  Should
we do something like this ourselves, as a "local hack"?  It's sure useful to
me.  I'm sure there's other examples out there of this sort of thing ...

Comments?

	- Greg