This message is intended to start a thread that can reach a
consensus regarding the short-term and long-term goals of the
guagga project.
SHORT-TERM GOALS
1. INITIAL RELEASE
Perhaps the most important short-term goal is to field a "released"
version based on zebra-pj. This should have the following attributes:
a. Minimum changes from zebra-pj. Perhaps only the name of the
executable and whatever else is absolutely necessary.
Rationale - widest possible ussage and feedback base.
b. Should work with existing zebra file structure and configuration
files without changes.
Rationale - widest possible usage and feedback base.
c. Third party daemons like IS-IS should not require any changes.
Rationale - widest possible usage and feedback base.
d. Should be available as tarball, RPM, and deb.
Rationale - easier to install than present CVS.
e. Should have gone through a PRE or RC cycle first which implies
that we first have a frozen release candidate and at least a minimum
feedback cycle.
f. Release notes for each deamon that capture current knowledge
of what works and what doesn't on various platforms.
Rationale - must meet the user expectations of a stable package that
works for most application out of the box without the need to
re-compile sources (at least for Linux).
g. 1.0.x version will become the stable tree. Next major stable
version can be planned to be 1.2.X.
Rationale - odd/even Linux style stable and development trees have
proven to work.
2. INITIAL DOCUMENTATION RELEASE
Minimal clean up of existing docs including numerous grammatical
errors.
Rationale - Clean English base version will facilitate translation to
other languages.
3. ESTABLISH ONGOING PROJECT PROCESS AND STRUCTURE
a. Separate sub-projects for Zebra, BGP, OSPF, RIP, etc.
b. Test Methodology.
Rationale - There are several sub communities of users. Some have
very simple needs. Some have a focus on OSPF. Some have a focus
on BGP. Separating by protocol will allow the project to scale
around each protocol. Decisions, maintenance, etc. revolving
around protocol allow them to separately evole with minimal
impact on the other sub projects. All of course may impact the
Zebra core.
LONG-TERM GOALS
TBD
-------------------------
I'm just offering the above to start off the discussion. I think
it is crucial to understand what we're doing before we start
doing it. I'd prefer to see the free for all take place in the
list discussion and not in the code. While it will take a few
days to sort this out, we will surely see the payback when the
actual work gets underway.
There appears to be much latent interest and many potential
contributors both for actual work on the code and documentation
base and for testing. If we want quagga to succeed we need to make
it appealing to potential contributers while at the same time
defending the stability of the suite.
Cheers
Wally
consensus regarding the short-term and long-term goals of the
guagga project.
SHORT-TERM GOALS
1. INITIAL RELEASE
Perhaps the most important short-term goal is to field a "released"
version based on zebra-pj. This should have the following attributes:
a. Minimum changes from zebra-pj. Perhaps only the name of the
executable and whatever else is absolutely necessary.
Rationale - widest possible ussage and feedback base.
b. Should work with existing zebra file structure and configuration
files without changes.
Rationale - widest possible usage and feedback base.
c. Third party daemons like IS-IS should not require any changes.
Rationale - widest possible usage and feedback base.
d. Should be available as tarball, RPM, and deb.
Rationale - easier to install than present CVS.
e. Should have gone through a PRE or RC cycle first which implies
that we first have a frozen release candidate and at least a minimum
feedback cycle.
f. Release notes for each deamon that capture current knowledge
of what works and what doesn't on various platforms.
Rationale - must meet the user expectations of a stable package that
works for most application out of the box without the need to
re-compile sources (at least for Linux).
g. 1.0.x version will become the stable tree. Next major stable
version can be planned to be 1.2.X.
Rationale - odd/even Linux style stable and development trees have
proven to work.
2. INITIAL DOCUMENTATION RELEASE
Minimal clean up of existing docs including numerous grammatical
errors.
Rationale - Clean English base version will facilitate translation to
other languages.
3. ESTABLISH ONGOING PROJECT PROCESS AND STRUCTURE
a. Separate sub-projects for Zebra, BGP, OSPF, RIP, etc.
b. Test Methodology.
Rationale - There are several sub communities of users. Some have
very simple needs. Some have a focus on OSPF. Some have a focus
on BGP. Separating by protocol will allow the project to scale
around each protocol. Decisions, maintenance, etc. revolving
around protocol allow them to separately evole with minimal
impact on the other sub projects. All of course may impact the
Zebra core.
LONG-TERM GOALS
TBD
-------------------------
I'm just offering the above to start off the discussion. I think
it is crucial to understand what we're doing before we start
doing it. I'd prefer to see the free for all take place in the
list discussion and not in the code. While it will take a few
days to sort this out, we will surely see the payback when the
actual work gets underway.
There appears to be much latent interest and many potential
contributors both for actual work on the code and documentation
base and for testing. If we want quagga to succeed we need to make
it appealing to potential contributers while at the same time
defending the stability of the suite.
Cheers
Wally