help-octave
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: The future of Octave


From: John W. Eaton
Subject: Re: The future of Octave
Date: Fri, 8 Dec 2000 11:06:25 -0600

On  8-Dec-2000, David Doolin <address@hidden> wrote:

| Yes!  Perfect answer: those who want matlab compatibility, fork it.

Generally, I think forking projects is a bad idea.  We have very
limited resources, so spreading them any thinner is not good.

| If the fork is good, and they can construct a mechanism keeping up with the
| Mathworks,

I don't think this is possible.  The MathWorks does not openly discuss
their development plans.  If you wait until their next release to find
out what is new, and what has changed, and what you need to `catch up'
on, then you are already many years behind at each new release.  I
believe it is a losing battle, and that is one of the primary reasons
that I am no longer interested in working on Octave as it is now.

| then it can always be merged back in later,

For fundamental new features, I'm not so sure that this would be
possible very often.

The `non-matlab-compatible' branch would presumably be innovating, and
not standing still.  It is likely that some of the innovations would
then be duplicated in incompatible ways by the next release of Matlab.
When there is overlap like this, you lose, because (assuming that
compatibility is a critically important goal) it means that you either
have to break compatibility with previous versions of the
`non-matlab-compatible' branch, or you have to assume the burden of
maintaining two incompatible ways of doing the same thing.  This has
happened in the past, and I expect it would happen again.

| two forks would not both  and jwe does not
| have to deal with that part of the code at all.  The onus is on those need
| it.  

jwe does not have to deal with the code at all, because jwe will
probably not be working on a project like that.  :-)

But, whoever is the maintainer of such a project would have to deal
with the code, because there would almost surely be conflicts and
divergence.  Merging would not be easy.  Just look at GNU Emacs and
XEmacs, as an example.  Even if the two groups could get together, it
would now require a huge effort to merge those projects back together.

FWIW, I'll stay in this discussion only as long as I feel I'm not
repeating myself too often.

jwe



-------------------------------------------------------------
Octave is freely available under the terms of the GNU GPL.

Octave's home on the web:  http://www.octave.org
How to fund new projects:  http://www.octave.org/funding.html
Subscription information:  http://www.octave.org/archive.html
-------------------------------------------------------------



reply via email to

[Prev in Thread] Current Thread [Next in Thread]