[quagga-dev 10883] Re: Vyatta & quagga - VyOS direction

Daniil Baturin daniil at baturin.org
Wed Oct 30 21:05:06 GMT 2013

Would be nice to at least find a way to enable those patches on linux at 
build time and ignore on anything else (and leave an easy way to 
implement the same for other OSes if it's relevant/possible there). I 
don't remember those patches and can't say if they are any 
#ifdef-wrappable, but I'd prefer this approach is possible.

All OSes are different, and slightly different behaviour and 
functionality is unavoidable IMHO.

On 10/31/2013 03:57 AM, Alexis Rosen wrote:
> On Oct 30, 2013, at 1:42 PM, Stig Thormodsrud <stig at ubnt.com> wrote:
>> I'm one of the developers on Ubiquiti's fork of vyatta/quagga.  Given that Vyatta is no longer using quagga,
> Huh? What are they doing then? Did they completely trash their existing product and replace it with something else??
>> I would certainly be interested in using what ever is deemed the "main" quagga upstream.
> There is no doubt that the previous answer on this topic is correct.
>> If I remember correctly some of the patches that shemminger did for vyatta's quagga that weren't taken upstream were related to link up/down issues.  I believe the problem with those patches was that they were linux specific.  Is it still a goal for quagga to support Solaris and all the BSD flavors?
> It appears to be. Given the desire not to further fragment the community, that's understandable, but (as we use NetBSD a lot, but not for our routers) not having those patches is too bad. Did they get reviewed? I don't remember them...
>> The changes that Ubiquiti has made to quagga have less to do with routing and more to do with presentation.  For example, we have several json versions of quagga show commands so that our GUI can more easily consume them.  Those change of course are in our GPL tarball, but I'm not sure if there would be much interest upstream in those changes.
> I can't speak for the maintainers, but ISTM that anything that keeps an active development team's code base closer to upstream (and therefore make it more likely that future patches will be easy to integrate) is worth considering, at least. If I were maintaining it, I'd ask for those changes to be configurable at build time, so people can run without it, and to make it easy to remove if the code ever becomes abandoned. But that's just me...
> /a
> _______________________________________________
> Quagga-dev mailing list
> Quagga-dev at lists.quagga.net
> http://lists.quagga.net/mailman/listinfo/quagga-dev

#!/usr/bin/env perl
@a=split(//, "daniil @ baturin  .  org" );# Daniil Baturin
@b=split(//,q/Px%!+o0Q6lh*7dp$. at 8#%|y{/);while($i<24){$_.=

More information about the Quagga-dev mailing list