On Sat, 2 Aug 2003, Wally Ritchie wrote:
WR> SHORT-TERM GOALS
WR>
WR> 1. INITIAL RELEASE
WR>
WR> Perhaps the most important short-term goal is to field a "released"
WR> version based on zebra-pj. This should have the following attributes:
WR>
WR> a. Minimum changes from zebra-pj. Perhaps only the name of the
WR> executable and whatever else is absolutely necessary.
If we take K's request quite literally, the minimum that we need to do is
change the name of the "zebra" daemon and zebra.conf file, change the
banner (not sure how we do this and also meet GPL requirements) and update
the documentation to refer to Quagga vs Zebra.
WR>
WR> b. Should work with existing zebra file structure and configuration
WR> files without changes.
Well, they'll need to change their zebra.conf to be quagga.conf.
WR>
WR> c. Third party daemons like IS-IS should not require any changes.
WR>
It has been a wile since I've played with ISISd but, is it functional
now? Perhaps we can contact the maintainer of that project and get it
folded into Quagga.
WR>
WR> d. Should be available as tarball, RPM, and deb.
WR>
I am not so sure that this is a requirement. A tarball is great but, do
we really need to release an RPM and a .DEB archive or should that be
something left to the maintainers of Redhat and Debian? I may be (hope
not) in the minority but, I would MUCH rather compile the code myself than
install a binary that someone else (even someone I trust) has compiled.
Every installation has its own unique set of circumstances. Some folks
don't need v6, some don't need RIP, some don't need ANY of the protocol
daemons but simply use the "2601" interface to configure interfaces on
their PC routers. In a quasi "appliance" environment (a dedicated PC
router), I tend to strip out as much as possible so I can fit the image on
as small a device as possible.
Then again, I guess there are folks who run/want-to-run routers who are
not comfortable with typing "./configure" and then "make install". That
scares the bejeebers out of me but, I guess it is a fact of life.
WR> Rationale - easier to install than present CVS.
WR>
WR> e. Should have gone through a PRE or RC cycle first which implies
WR> that we first have a frozen release candidate and at least a minimum
WR> feedback cycle.
I agree with this 100%! Nothing was worse than seeing
"zebra-0.xx" available and saying to yourself, "Man... I want to stay
current but, what is going to break if I upgrade?" I remember more than
one upgrade that would not use existing config files - absolutely no
mention that backwards compatability was not included with the new
"features."
WR>
WR> f. Release notes for each deamon that capture current knowledge
WR> of what works and what doesn't on various platforms.
WR>
WR> Rationale - must meet the user expectations of a stable package that
WR> works for most application out of the box without the need to
WR> re-compile sources (at least for Linux).
I agree that we need release notes and further, they need to be
maintained. I don't know that the "out of the box" is going to buy us
anything though. Do we simply want to grow the userbase or do we want
people contributing to the code? I'm not a huge fan of artificial
barriors to entry but, if someone can't even compile the code, what are
the chances that they'll contribute anything besides whining and
complaining on the quagga-users list?
WR>
WR> g. 1.0.x version will become the stable tree. Next major stable
WR> version can be planned to be 1.2.X.
WR>
WR> Rationale - odd/even Linux style stable and development trees have
WR> proven to work.
Definately!
WR>
WR> 2. INITIAL DOCUMENTATION RELEASE
WR>
WR> Minimal clean up of existing docs including numerous grammatical
WR> errors.
I can help here.
WR>
WR> 3. ESTABLISH ONGOING PROJECT PROCESS AND STRUCTURE
WR>
WR> a. Separate sub-projects for Zebra, BGP, OSPF, RIP, etc.
WR>
WR> b. Test Methodology.
WR>
WR> Rationale - There are several sub communities of users. Some have
WR> very simple needs. Some have a focus on OSPF. Some have a focus
WR> on BGP. Separating by protocol will allow the project to scale
WR> around each protocol. Decisions, maintenance, etc. revolving
WR> around protocol allow them to separately evole with minimal
WR> impact on the other sub projects. All of course may impact the
WR> Zebra core.
WR>
WR> LONG-TERM GOALS
Long-term goal #1: Get WR to stop referring to the code as "Zebra." ;-)
--
John Fraizer | High-Security Datacenter Services |
President | Dedicated circuits 64k - 155M OC3 |
EnterZone, Inc | Virtual, Dedicated, Colocation |
http://www.enterzone.net/ | Network Consulting Services |
WR> SHORT-TERM GOALS
WR>
WR> 1. INITIAL RELEASE
WR>
WR> Perhaps the most important short-term goal is to field a "released"
WR> version based on zebra-pj. This should have the following attributes:
WR>
WR> a. Minimum changes from zebra-pj. Perhaps only the name of the
WR> executable and whatever else is absolutely necessary.
If we take K's request quite literally, the minimum that we need to do is
change the name of the "zebra" daemon and zebra.conf file, change the
banner (not sure how we do this and also meet GPL requirements) and update
the documentation to refer to Quagga vs Zebra.
WR>
WR> b. Should work with existing zebra file structure and configuration
WR> files without changes.
Well, they'll need to change their zebra.conf to be quagga.conf.
WR>
WR> c. Third party daemons like IS-IS should not require any changes.
WR>
It has been a wile since I've played with ISISd but, is it functional
now? Perhaps we can contact the maintainer of that project and get it
folded into Quagga.
WR>
WR> d. Should be available as tarball, RPM, and deb.
WR>
I am not so sure that this is a requirement. A tarball is great but, do
we really need to release an RPM and a .DEB archive or should that be
something left to the maintainers of Redhat and Debian? I may be (hope
not) in the minority but, I would MUCH rather compile the code myself than
install a binary that someone else (even someone I trust) has compiled.
Every installation has its own unique set of circumstances. Some folks
don't need v6, some don't need RIP, some don't need ANY of the protocol
daemons but simply use the "2601" interface to configure interfaces on
their PC routers. In a quasi "appliance" environment (a dedicated PC
router), I tend to strip out as much as possible so I can fit the image on
as small a device as possible.
Then again, I guess there are folks who run/want-to-run routers who are
not comfortable with typing "./configure" and then "make install". That
scares the bejeebers out of me but, I guess it is a fact of life.
WR> Rationale - easier to install than present CVS.
WR>
WR> e. Should have gone through a PRE or RC cycle first which implies
WR> that we first have a frozen release candidate and at least a minimum
WR> feedback cycle.
I agree with this 100%! Nothing was worse than seeing
"zebra-0.xx" available and saying to yourself, "Man... I want to stay
current but, what is going to break if I upgrade?" I remember more than
one upgrade that would not use existing config files - absolutely no
mention that backwards compatability was not included with the new
"features."
WR>
WR> f. Release notes for each deamon that capture current knowledge
WR> of what works and what doesn't on various platforms.
WR>
WR> Rationale - must meet the user expectations of a stable package that
WR> works for most application out of the box without the need to
WR> re-compile sources (at least for Linux).
I agree that we need release notes and further, they need to be
maintained. I don't know that the "out of the box" is going to buy us
anything though. Do we simply want to grow the userbase or do we want
people contributing to the code? I'm not a huge fan of artificial
barriors to entry but, if someone can't even compile the code, what are
the chances that they'll contribute anything besides whining and
complaining on the quagga-users list?
WR>
WR> g. 1.0.x version will become the stable tree. Next major stable
WR> version can be planned to be 1.2.X.
WR>
WR> Rationale - odd/even Linux style stable and development trees have
WR> proven to work.
Definately!
WR>
WR> 2. INITIAL DOCUMENTATION RELEASE
WR>
WR> Minimal clean up of existing docs including numerous grammatical
WR> errors.
I can help here.
WR>
WR> 3. ESTABLISH ONGOING PROJECT PROCESS AND STRUCTURE
WR>
WR> a. Separate sub-projects for Zebra, BGP, OSPF, RIP, etc.
WR>
WR> b. Test Methodology.
WR>
WR> Rationale - There are several sub communities of users. Some have
WR> very simple needs. Some have a focus on OSPF. Some have a focus
WR> on BGP. Separating by protocol will allow the project to scale
WR> around each protocol. Decisions, maintenance, etc. revolving
WR> around protocol allow them to separately evole with minimal
WR> impact on the other sub projects. All of course may impact the
WR> Zebra core.
WR>
WR> LONG-TERM GOALS
Long-term goal #1: Get WR to stop referring to the code as "Zebra." ;-)
--
John Fraizer | High-Security Datacenter Services |
President | Dedicated circuits 64k - 155M OC3 |
EnterZone, Inc | Virtual, Dedicated, Colocation |
http://www.enterzone.net/ | Network Consulting Services |