From: Quentin S. <qsp...@ie...> - 2004-06-11 15:30:17
|
Mark P. Esplin wrote: >I am trying to figure out how octave-forge development works. For the main >part of octave, John Eaton set's the direction, adds patches etc., but how >about for octave-forge? When I look at the "Octave-forge developer's guide" >at http://octave.sourceforge.net/ it has instructions for adding modules to >octave-forge. Does each module's author maintain the module? I probably >don't have the ability or the time to add major modules to octave-forge, but >I can do some bug-fixes, documentation, etc. How would I go about doing >that? Just having a few comments on what works and what doesn't seems like it >would be helpful. Should this go on http://wiki.octave.org/? Maybe we >could avoid some of the frustration expressed recently by Tom in his post to >he...@oc.... > > This and another recent post by Dirk to the octave list about splitting octave-forge because of dependencies has got me thinking. Octave-forge has become quite large and includes some very stable as well as some bleeding-edge code. I seem to recall that John has expressed a desire to avoid adding too much extra stuff to the core octave distribution, while at the same time some of the octave-forge functions have become a necessity for many people (including myself). Many of them roughly approximate the MATLAB "toolboxes", and some of them comprise easy solutions to questions that seem to come up on help-octave at least weekly (how do I save a figure, etc...), so the evidence would suggest that it's not advertized well enough. I'm not sure about the solution to that problem, but I would like to suggest we split octave-forge into some smaller packages. Here's a suggestion: "octave-extras" or "octave-toolboxes": a well-tested core of octave-forge with minimal external dependencies "octave-geom" and "octave-symbolic": separate packages that depend on external packages (like GiNaC and qhull) "octave-forge": bleeding edge stuff I welcome any thoughts on this. -Quentin |