On Thu, Dec 04, 2014 at 08:25:08AM -0500, Greg Troxel wrote: > > David Lamparter <[email protected]> writes: > > > On Thu, Dec 04, 2014 at 07:42:06AM -0500, Greg Troxel wrote: > >> David Lamparter <[email protected]> writes: > >> > Maintenance burden isn't caused by change, it's caused by existence. > >> > Even if it doesn't change, every time we adjust something - like adding > >> > a command line parameter somewhere - we would really need to make sure > >> > that the init scripts are in order. > >> > >> That's an unreasoable strawman. If it doesn't happen, someone can > >> submit a patch, just like any other bug. This is basically a non-issue > >> in practice. > > > > I'm happy to hear that we can ignore the BSDs on future kernel API > > changes, and just wait for someone to submit a patch, just like any > > other bug ;) > > That coment comes across as gratuitously hostile. I am having a hard > time following you.
Erp, that was what the smiley was about. I don't see the C code and the shell scripts as that different. They're both code that needs occasional updating, can have security issues, needs porting to different systems, etc. Sure, the init scripts are on the lower end of the maintenance effort - just like some of the C code (e.g. some memory management code, hashes, linked lists, etc.) - but it's still not free. And for the C code, at least we have the compiler telling us, yep, it still compiles. The init scripts just lie there. And they *do* rot, if only slowly. > quagga has to continue to run on the various systems it runs on (and > agreed that Solaris has fallen off the wagon). The serious issues are > about the zebra/kernel interfaces, not init scripts, and we need to be > careful about those. > > For init scripts, the likely problems are from incompatible changes to > arguments in daemons. Having the init scripts around is a clue that > such changes cause lots of ripples, and whether the pain is in our tree > or elsewhere it's still pain that is best avoided. Well, actually, I'd argue more changes on the init scripts come in from distros changing things, but that's mostly a Linux fad. But - cue to recent news reports on FreeBSD considering systemd. > What I meant was that if there's a change, and there's a small breakage > in one of the init scripts because of it, it's not a huge big deal, and > it's not even that likely. So setting up "we would absolutely have to > ensure that doesn't happen" as a goal to then justify "delete it all" > doesn't make sense. I think the more interesting case here is external changes. The way Quagga's command line arguments work haven't seen relevant changes in ages. The redhat/ directory in Quagga, on the other hand, has seen several updates to fix it up to match external changes. These weren't really our areas of responsibility, IMHO. > > Things should either be around, maintained and current, or they should > > be removed. Outdated cruft that is carried in an official repository > > has negative value, because users and developers alike will stumble over > > it, be misled by it and waste their time. > > If something is demonstrated to be non-working and non-maintained, I'm > ok with deleting it. So far you've pointed out that the solaris > initscripts are in that category (because no one has reported that > quagga even works at all on Solaris). > > > Really, these scripts, once written, should hardly ever change. And if > they do, I'd expect it to be about arguments to daemons. So I think a > process to evict them is effort not well spent. That may hold for pkgsrc/ and ports/, yet redhat/'s git history tells a different story. -David _______________________________________________ Quagga-dev mailing list [email protected] https://lists.quagga.net/mailman/listinfo/quagga-dev
