[quagga-users 12334] Re: quagga evolution ?
gernot.schmied at chello.at
Tue Jun 7 08:06:56 IST 2011
great to hear from you, hope you are doing well! Still located in
Regarding quagga stewardship & direction:
I regret, that the lack of resources prevented the project from
achieving what it rightfully deserves - more popularity and a larger
deployment base. One can also argue about better ways of quality
assurance or software project management, but that was not my primary
reason for expressing my frustration - again. I understand from
following the postings, that your primary concern is the way patches are
submitted and verified.
The major questions for me remain:
Is the number of bugs decreasing? Is there an effective method in place
that prevents regressions? Does the architecture itself make it so
difficult or does it scale for the future?
Why was everyone in the past so reluctant to call a feature freeze and
move to a major release number to indicate, that the *project
maintainers* consider it production grade? This particular arguing is
going on for years now.
To sum it up:
I do not think that all critical issues that are holding back quagga
evolution are resource related.
Am Montag, den 06.06.2011, 12:12 +0100 schrieb Paul Jakma:
> Hi Gernot,
> How's things? :)
> On Sun, 5 Jun 2011, Gernot Schmied wrote:
> > Every now and then the question arises, where quagga is heading in terms
> > of a feature freeze 1.0 production release. This discussion is going on
> > now for years, still regressions and feature bloating but now
> > convergence in terms of a release that can be deployed and *supported*
> > in a production grade environment and a clear signal, that the project
> > maintainers *want* to move it in that direction.
> I think we've been quite conservative the last while about accepting
> > Does quagga has a future in terms of acceptance or will it always be a
> > research project just the developers consider production grade? Is it a
> > problem of software project management or something else?
> So there's a couple of ways to look at this:
> * Quagga users who are disappointed with support from quagga.net
> Such users have a number of options depending on what kind of support they
> If they're expecting some commercial level of support, well then they
> should go contract with someone with or some organisation which retains
> staff with Quagga expertise. They could buy a support contract from a
> general Unix/Linux distribution vendor (making sure to *tell* the sales
> people they're buying it with a view to Quagga support) or even perhaps
> from a distro vendor which specialise in routing and retain Quagga &
> kernel networking engineers.
> Unpaid volunteers can not offer the kind of support commercial users tend
> to want. It's not realistic to expect it either.
> If the user has expertise, doesn't want to pay for support, well they may
> wish to chip in and help (and see next section).
> If the user doesn't want to pay for support and doesn't want or can't fix
> things themselves, then they may have to have patience and or prepare for
> * Quagga developers who are disappointed with Quagga.net maintenance
> This is the class of people who have the resources to support their own
> immediate support issues (e.g. because they're making a living from it, or
> using Quagga in some product), for whom Quagga.net is the upstream. From
> whom everyone else presumably must get their support.
> This one would take longer to cover. Some of the problems here are:
> - Lack of QA resources possibly
> - The project has perhaps failed to foster more test-driven development
> - Limited maintainer resources
> - Failure to foster a clear review/revise/test contribution process,
> leading to contributors sometimes having unrealistic expectations.
> - Next to 0 face-time between those interested in Quagga long-term (I've
> only ever met 2 other Quagga maintainers, and 1 contributor, I think).
> A more expansive discussion on this part is probably better done over on
More information about the Quagga-users