> Getting back to your CVS comments from yesterday. I agree, we need to
start
> committing files to CVS. There are approximately six people working
> independently on the EigerStein update. Putting these individual pieces
> into CVS will allow all of us to build off of each others efforts.
>
> First, Charles this looks like a significant update. Are we still going to
> call it EigerStein, or have you decided on a new name?
Depends on what you're talking about (see next answer, below)
After consulting my wife (a professional gardner), I intend to use her
suggestion of 'Quercus' (latin for Oak) as a 'family' name. The initial and
subsequent releases would be named for a particular varieties of Oak:
Quercus macrocarpa - Burr Oak
Quercus rubra - Red Oak
Quercus alba - White Oak
and so on, with subsequent major releases using a different species (like
Maple, Spruce, etc). The latin and english names could be used somewhat
interchangably...
> Second, are we creating a release that branches from 2.9.8, or ESb2?
There are two issues at hand. One is an update of ES2Beta, which should
simply be the existing ES2Beta + David's updated binaries for various
libraries and programs that had security holes + latest versions of the
encluded LRP packages + possibly a new kernel. This should probably be ES3
or something...
I'd also like to see a whole new distribution put together, as previously
discussed. This would use SeaWall (or one of the other firewall packages)
for the firewall rules, might be based on a 2.4 kernel and perhaps even an
updated libc. I don't think it matters much what distribution we base this
off of (unless Butterfly actually appears and looks suitable), as long as we
either pick a distribution to develop on, select a distribution that already
squeezes packages for an embedded environemnt (unlikely to solve all our
problems), or (preferred) build a compile environment that can be installed
on any generic linux system, complete with local libraries, so it won't
matter what's running on the development box.
We would, however, need to decide on a general filesystem layout, rc.d
standards, and the like. Ideally, this layout would match a mainstream
distribution (like debian, redhat, caldera, or similar), so folks wouldn't
be quite so lost when trying to figure out how everything ties together, and
creating packages would likely be easier (I'm envisioning taking an RPM or
DEB, applying a few 'tweaks', and making an LRP or it's new equivelant).
Charles Steinkuehler
http://lrp.steinkuehler.net
http://c0wz.steinkuehler.net (lrp.c0wz.com mirror)
_______________________________________________
Leaf-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/leaf-devel
