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 ;) 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. > > I don't think anyone even knows whether the solaris files are in order > > - I certainly don't. > > True, but that's not really relevant to the larger discussion. It's valuable as detached example to discuss without getting people's personal attachments involved. I have some strong opinions about systemd, for example :) > > And, if Solaris wants to change something - doesn't it make more sense > > for them to change it on their end? Why should we be involved? > > It's not "solaris" that wants to change something. It's the glue code > between the solaris init system and quagga. This doesn't really belong > in some solaris packaging system any more than it belongs in quagga. The Solaris init system glue is still Solaris specific. I'd say it belongs where it causes the least time churn globally, i.e. summed over the involved parties. That, IMHO, is quite clearly the Solaris side by merit of numbers - they maintain the same kind of init scripts for a zillion of things. > > Unfortunately, current developments (systemd) go in the opposite > > direction, with more init systems to support, and even between systems > > using the same init system the files are ever so slightly different. > > That's pretty crazy; someone should file a bug with systemd :-) Part of the problem seems to be that the systemd bugtracker goes to /dev/null almost as efficiently as our own :D > But seriously, it seems there are multiple init syztems on linux, and a > vast number of distributions. So having the start/stop files for the 2 > or 3 standard approaches makes sense, and distributions that require > variant systemd files can patch them. Yeah, that's what's in redhat/ (which is rather misnamed, it contains generic SysV init scripts, systemd unit files, and a little redhat-specific cruft.) Maybe we should clean that up. > > Renaming isn't a pain, not in git ;) > > It still takes a commit to munge all the paths. Oh, *that* is not the problem. I'd be overjoyed if we got more patches in that are as rubber-stamp reviewable as a rename. > > Sounds to me like the bits that are shared between systems belong in > > some kind of a "contrib/" directory (including other things that aren't > > really Quagga, but that are common and make sense to be bundled with > > Quagga). And the things that aren't shared over a relevant set should > > go. > > Calling it contrib is a distinction with a real difference. This would > just be meaningless churn, and I think we should let it be. It'd clarify that we're not actively maintaining some of it. Maybe we should apply the label more fine-grainedly. -David _______________________________________________ Quagga-dev mailing list [email protected] https://lists.quagga.net/mailman/listinfo/quagga-dev
