cvs commit: src/contrib/bsnmp - Imported sources

[Harti Brandt]

On Mon, 10 Nov 2003, Kris Kennaway wrote:

KK>On Mon, Nov 10, 2003 at 10:51:34AM +0100, Harti Brandt wrote:
KK>> On Mon, 10 Nov 2003, Kris Kennaway wrote:
KK>>
KK>> KK>On Mon, Nov 10, 2003 at 10:37:54AM +0100, Harti Brandt wrote:
KK>> KK>
KK>> KK>> KK>What is this?  I don't remember it being discussed on the mailing
KK>> KK>> KK>lists, which is usual before importing new software into FreeBSD.
KK>> KK>>
KK>> KK>> That is the base for the NgATM ILMI daemon. While writing the commit
KK>> KK>> message I was thinking about whether or not to include an explanation into
KK>> KK>> the commit message. We talked about this on the atm mailing list approx. a
KK>> KK>> year ago.
KK>> KK>
KK>> KK>That's pretty narrow distribution, and self-selected for people who
KK>> KK>think it's a good idea.
KK>>
KK>> Well, discussing ATM issues with folks who don't care about ATM doesn't
KK>> make much sense though. The best you get is no response at all. If the
KK>> problem is that it is in contrib - the reason is that although the
KK>> development platform is FreeBSD this is actually portable code that runs
KK>> also on Solaris and Linux and has a different build environment for this
KK>> (gmake and autoconfig).
KK>
KK>The problem is that it's code that is useless to 99% of the FreeBSD
KK>userbase, so it's unclear whether it belongs in the base system
KK>instead of ports.

Maintaining code that is in the kernel or near to it is amost impossible.
I maintained the code for two years this way. It is simply a nightmare
because you have to change your code, make up new distributions on a
weekly basis and to answer user you ask why this and that does not patch
or not work and to send them individual patches. You'll have to tell them
to update to this or that version of the kernel. Most of the code is under
NOATM so it shouldn't pose a problem for people who don't need it. Also
this is is a mid-term replacement for the otherwise un-maintained HARP
code. In contrast to HARP there is also a regression test-suite for the
core protocols that run the ATM-Forum/ITU-T test suites (this will be a
port)  so maintenance will be a lot easier than with current ATM code.

I remember a discussion of breaking the base system into packages. Perhaps
this would be the right way to maintain this kind of code. I would happily
factor out everything ATM related into such a package.

harti
-- 
harti brandt,
http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private
brandt at fokus.fraunhofer.de, harti at freebsd.org