Mailing List Archive

[Quagga-dev] Re: Now what?
On Sat, 2 Aug 2003, James R. Leu wrote:

> So Quagga community, where do we go from here? What's the
> first order of business? More 'admin' stuff, or can we
> start digging in?
>
> No matter really, but I think one of the first tasks
> should be to release a version of 'Quagga' which contains
> all of the patches Paul has been gathering. This release
> will set the gears in motion and establish the Quagga fork.
> There is nothing worse then a project without released code ....
>
> --
> James R. Leu


I agree. Paul, if you can go through the code and make sure it says
"Quagga" in all of the appropriate places (remember, K. didn't want us to
use the Zebra name so, we should remove all references not required by
GPL) and roll a tarball, I think that would make a good start.

---
John Fraizer | High-Security Datacenter Services |
President | Dedicated circuits 64k - 155M OC3 |
EnterZone, Inc | Virtual, Dedicated, Colocation |
http://www.enterzone.net/ | Network Consulting Services |
[Quagga-dev] Re: Now what? [ In reply to ]
> -----Original Message-----
> From: quagga-dev-bounces@lists.quagga.net
> [mailto:quagga-dev-bounces@lists.quagga.net] On Behalf Of John Fraizer
> > No matter really, but I think one of the first tasks
> > should be to release a version of 'Quagga' which contains
> > all of the patches Paul has been gathering. This release
> > will set the gears in motion and establish the Quagga fork.
> > There is nothing worse then a project without released code ....
> >
> > --
> > James R. Leu
>
>
> I agree. Paul, if you can go through the code and make sure it says
> "Quagga" in all of the appropriate places (remember, K.
> didn't want us to
> use the Zebra name so, we should remove all references not required by
> GPL) and roll a tarball, I think that would make a good start.
>

Actually, the name issue in the code is a bit more complex.
Zebra is everywhere, in the API for daemons, defines, includes,
etc. etc. Just changing every occurance will break things
like the IS-IS daemon.

It's of course possible to duplicate ZEBRA_VARIABLE_XX with
QUAGGA_VARIABLE_XX but this increases complexity and leads to
errors when they get out of sync. It could be handled by a
"compatibility" layer that makes all ZEBRAxxxx deprecated and
uses compatibility defines that eventually go away.

The key issues regarding name are:

1. Is it really necessary to purge Zebra names and if so to
what degree??

2. How is compability with existing code not in the fork, like
IS-IS or who knows what, maintained???

3. How likely is QUAGGA to survive as the name?? Perhaps changing
zebra in names to simply Z, QZ, or ZQ is something that could
could survive any future name changes.

The name issue, if of course just one of many issues. While there
seems to be a lot of pent up desire to just get on with it, doing
so willy nilly is likely to just muck up the works. Furthermore,
success depends on continued contributions both to the code base
and perhaps even more importantly, testing of release candidates
by a large community with diverse applications.

I'm here for one reason. I just want a stable open source route
processor with BGP, OSPF, and RIP that is suitable for production
use and actively maintained. I think that this want is probably
the "common need" of everyone.

I wouldn't be here if zebra or even zebra-pj met this need. Just
having a hacked zebra-pj that adds every patch in sight is
definitely not going to make things better. Users that are able
will just be forced to go back to zebra as the base and roll
their own patches and maintain their own tree.

What needs to be done is the following:

1. The LIST has to be fixed so it works properly.
2. The CHARTER for the project needs to be established.
3. The short term and long term GOALS need to be defined.
4. The PLAN for meeting the goals has to be developed.
5. Willing contributers need to be identified.
6. The plans need to be executed by the contributers.
7. The RESULTS need to verified as meeting the GOALS.
8. Iterate 3 - 7 continuously.

We should keep things as simple as possible - but no simpler.

I intend to start threads for charter and goals and let's
see what kind of consensus emerges. We can then move on to a
plan for meeting the goals.

Cheers

Wally