Date: Mon, 20 Aug 2001 00:59:52 -0700 (PDT) From: Ted Mittelstaedt <tedm@toybox.placo.com> To: Mike Meyer <mwm@mired.org> Cc: Ted Mittelstaedt <tedm@toybox.placo.com>, questions@FreeBSD.ORG Subject: RE: IDS Message-ID: <998294392.3b80c3787dd97@mail.freebsd-corp-net-guide.com> In-Reply-To: <15232.35010.655197.502835@guru.mired.org> References: <15232.26162.667917.436954@guru.mired.org> <004801c12923$94edef60$1401a8c0@tedm.placo.com> <15232.35010.655197.502835@guru.mired.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Quoting Mike Meyer <mwm@mired.org>: > Ted Mittelstaedt <tedm@toybox.placo.com> types: > > >You seem to be arguing that, because ports are abandoned, people > > >shouldn't bother submitting them. > > No - just that if your going to submit a port, then please stick > around and > > keep it active. > > Or at least plan on it. > > > I'm not familiar with that case, but unless the umich software > completely vanished, I don't see how people would have been better off > if it had never existed. They had the umich software to run when > nothing else was available. The OpenLDAP developers had an > implementation to test against. Sure, having to switch later was > probably more painfull than just using OpenLDAP to begin with, but was > it more painfull than having nothing at all? > The particulars of that case was that the people at University of Michigan that started the LDAP code basically wrote it so that it would compile and build properly on only 1 platform - Solaris 2.4 - despite claiming in the documentation how portable it was. They messed with the code for a few years (during which nobody really paid any attention to them) until the major mail clients in use began supporting LDAP as an address directory lookup protocol. By then U of Mich had either lost total interest or was attempting to peddle the code elsewhere or some such and a giant collection of patches was amassed to get the thing to compile and build, and even then only the database part of it worked, the replication servers were hopeless. Naturally, the OpenLDAP people probably did test against the umich code (and used some of it as a base for the OpenLDAP I think) but of course the real authoratative reference was the RFC itself. Meanwhile during that time if you wanted an address book for your mail system you had a choice of either hacking on buggy old Umich LDAP code (that was probably stuffed with buffer overruns) or in basically beta testing OpenLDAP. Of course today things are fine, the OpenLDAP code is strong and the old Umich LDAP code has been slid into the history books. But I fault the folks at U of Mich who were given dozens of patches and bug reports and didn't lift a finger to fix their distribution. Take a look at Cistron Radius to see how one of these transitions is being done right. Miguel has moved on to FreeRadius, the new super-duper replacement. But he hasn't turned his back on the radiusd-cistron code and they still keep releasing bugfixes to it that people give to them. > > Documentation is still the most important part of an application. If > you can't USE the application, it's useless. To quote a Sybase > T-shirt, without documentation it's just code. > Yup - because Sybase doesen't let you see the code. Documentation is required for black boxes. > > running the software! After all, the software package that the > developer > > submitted to the FreeBSD project already contains the most > authoratative and > > best documentation that there it - the source code! > > Most authorative, yes. Best? If that were true, we wouldn't need > anything else - including the books. > Many don't. But your point about electronic documentation is well taken. At the least, sites like the CVS Instructions page listed earlier really ought to link back to the FreeBSD website rather than just recopying. Ted To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?998294392.3b80c3787dd97>