Date: Mon, 10 Nov 2003 11:24:50 +0100 (CET) From: Harti Brandt <brandt@fokus.fraunhofer.de> To: Kris Kennaway <kris@obsecurity.org> Cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/contrib/bsnmp - Imported sources Message-ID: <20031110111035.G29745@beagle.fokus.fraunhofer.de> In-Reply-To: <20031110100936.GA8977@xor.obsecurity.org> References: <200311100853.hAA8rchS095414@repoman.freebsd.org> <20031110103409.R29745@beagle.fokus.fraunhofer.de> <20031110104611.U29745@beagle.fokus.fraunhofer.de> <20031110100936.GA8977@xor.obsecurity.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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@fokus.fraunhofer.de, harti@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031110111035.G29745>