On Mon, Jun 01, 2015 at 03:37:33PM +0100, Paul Jakma wrote: > On Sun, 31 May 2015, David Lamparter wrote: > > As such, I'd mark the entire field as experimental (i.e. we won't care > > about API or CLI breakage for VRFs), and let the bright people on this > > list apply their engineering chops to it. If some patchsets are badly > > engineered, we can point out those specific engineering issues at that > > occasion. > > I'm not so sure. > > Not so long ago we weren't even able to change the default of the > link-state command to something that'd suit the overwhelming majority of > users, because there might be some (likely small and transient set) of > users with broken setups that might (incorrectly) depend on it. > > If we put VRF in in a way that people start depending on aspects of this > particular implementation (or can be argued is possible), my experience > (not just from link-state, but other stuff) is that externally visible > things can be difficult to change once in.
Well, this is a nice argument for printing a more obvious CLI warning when a user uses any VRF feature. We should add that - anyone wanna do a followup patch? (FWIW, I strongly argued the link-detection issue because I personally knew setups that get broken by this, and in a very subtle non-obvious way. This is not the case with VRF support.) > > For all we know, we can later chop off the variants that didn't end up > > useful much. > > Or we just design it right now. Except, we don't now right now which ones are the useful bits. More interestingly, we *can't* know some of the answers, because they involve determinations like "what will users run," "will someone put this on OpenWRT," or "will someone provide feedback from adapting this to their FancyHardwareSwitchChip or *BSD or NextLinuxKernelAPI." > I'm sure no bright engineer would object to having a design discussion, > and ensuring that the proposal meets not just their own requirements but > any wider requirements of the community. That's part of good engineering. I'm a bright engineer objecting to -further- design discussion. We already have discussed the process model, and the consensus is "do both." Further discussion IMHO crosses the line into bikeshedding. The issue here is simply that "design" is not a well-delineated area. First, we designed the process model. Next, we're designing API commands. Then, we're designing how tasks are split into functions and exposed in headers. Then, we're "designing" what the code to read from a socket looks like. I bet /someone/ /somewhere/ had a design discussion on what assembler instructions to use ;) And, really, I don't see how we would arrive at a positive outcome from this "design discussion" - especially since it appears to me that you're having a discussion with... yourself? At least, I don't see anyone else trying to further discuss this. If I'm having tomatoes on my eyes (wonderful german idiom ;) and am failing to see someone, could that/these someone please speak up? -David P.S.: I really hope I didn't just jinx myself, I have code on my laptop that uses ISO C11 stdatomic ops, which does go down to the asm level ;) _______________________________________________ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev
