Re: Adding functions to octave base?

[fork]

John W. Eaton <jwe <at> octave.org> writes:
> On  2-Aug-2010, fork wrote:

Prof. Eaton -- First of all, let me say that I am HUGELY GRATEFUL for your 20
years of hardwork on Octave -- yet again, I am able to inherit a massive amount
of capital (human, economic, etc) with almost no effort on my part.  I am not
complaining, I am only wishing for continual improvement to what I see as the
next big free software event.
 
> | So why don't we bring everything into the main hg tree?
> 
> Because there is a lot of stuff in Octave Forge for which (at least
> some of) the Octave maintainers to not want to maintain.  There may
> also be licensing or political issues.

I would imagine that the maintainers of the offsite packages would be willing
(maybe even happy) to maintain their code in the main tree.  I am sure there
would be some fringe types who wouldn't, but they could go their own way. And if
the package isn't being maintained in SF, I bet it is (at least a little) more
likely to find a maintainer if it is the main tree. 

An absorption process could happen gradually starting with the big important
packages like statistics and optim (I'm sure others have their candidates).  I
am not suggesting we just graft forge on to the main tree without a whole lot of
pruning and editing -- sorry if I sounded like that -- that would be horrible!  

In Postgres there is a contrib directory that is maintained in the VCS but is
for non-core code and bug reports on that code still get handled centrally, it
is subject to the same formatting scripts, and the core maintainers will drop
you / get on your butt if your part of it is ill-maintained or is redundant to
the rest of the project.  Often contrib packages make their way into the main
codebase as they get tested and depended on.  Perhaps this would be a good 
model.

> | (Including emacs mode files -- my latest headache...?)
> 
> Emacs mode files should disappear from Octave.  They are part of Emacs
> now.

It isn't included in xemacs, though it is in regular emacs, at least for the
windows version I use at work.  However, ... octave still receives bug reports
about it, and I don't have a clue who is responsible for it.

> | Not sure how to go about this, as it is a big project.  However, a
> | huge part of the appeal of Python is its batteries included
> | philosophy, and the Octave project could do that too.
> 
> Are all packages written for Python checked in to the core Python VCS?
> Maintained by the core developers of Python?

Not "all" -- of course not -- but a lot are brought in.  Often a package will be
hosted separately for a while as it is first developed, Python people will see
that there is a need for a canonical version of the package, there will be
discussion, then the package AND maintainers will get absorbed into the main
project.  I could be wrong, but I think different parts of the codebase have
local experts.  Does Guido maintain unittest?  No, the unittest people do, but
at least everyone knows where everything is when they submit a bug report...

This approach avoids the chaos plaguing Perl's library, where there are 10
different libraries all for sending email, if you want to improve email handling
in Perl you have no idea where your patches should go, there is no consistency
between scripts, etc.  (not that I am suggesting an smtplib for octave ... oh
wait, I could use that!)  

I just read Judd's recommendation for keeping the separation, with Soren's
overwork as partly a reason:  I think Judd has a good point, but the problem is
that there are not enough maintainers, not that the VCS structure is currently
perfect, methinks.  I would hazard that a single well kept tree would be a
better invitation for contributors than the bifurcated mess that is 'Forge.

Thanks to JWE and Judd for taking the time to respond, and here's to debate; I
hope I can contribute enough in the future to justify my current complaining...