Re: policy for release branch

[Robert T. Short]

Please understand, I am not criticizing.  I am just presenting a point of view in
the hope that it might be helpful.  In the end, I have no complaints about the
way things are done because octave is and has always been a really decent
piece of software.

Jaroslav Hajek wrote:

I think a more general statement is:  octave can't compete with MATLAB.
What octave provides is a good, solid tool that does a lot of what MATLAB
does but at a substantially lower cost.
    

No, that's not true. Octave can also do a number of things Matlab
can't do, or does some things better.

  

Well, now.  Make a list of things octave does better.  Send that to The Mathworks
as a feature request.  *If* they decide they care, MATLAB will do all of those things
and more by the next release.  They have resources that we don't.

If you want some idea of the time and money spent by the Mathworks, look at
the list of U.S. patents that have been issued in the last few years.  I counted over
80 issued just since 2005.

No, octave CAN NOT compete with MATLAB.  As I said, octave provides a very nice,
well designed tool that does a lot of what MATLAB does but at a much better cost
(caveat, free software is not really free) and with the advantages of open source. 
It is important to understand that octave is a niche product and appeals to a certain
type of user.  When you embrace that concept, then it becomes much easier to set
expectations and priorities.  As with any project a sense of mission and expectations
is vital to success.

Looking at it differently, I have been a MATLAB user since someone gave me the
original FORTRAN source something like 20 years ago.  I worked with handful of
colleagues that had that code and used it regularly (and, as it turned out, probably
illicitly but we didn't know that at the time) .  By the time octave came along,
MATLAB was a full-fledged commercial product.  I have had access to both
MATLAB and octave ever since, and have always used octave as my preferred
tool even though it has been mostly less capable than MATLAB.  EVERY OTHER
PERSON in that initial group has stayed with MATLAB because they don't have
to build from source, they can buy toolboxes that are uniformly reliable, they
don't have to worry about crashes, etc., etc.  The fact that most of them have
moved away from unix and into the Microsoft Windows environment is a major
issue as well.

The people I am talking about are all experienced folks with reasonable
computer skills and sophistication, just less willing to spend the time on the
tool.  From the point of view of cost-effectiveness, MATLAB probably wins
anyway.  MATLAB isn't cheap software, but the hours that it takes to make
"free" software usable probably overwhelms the cost of maintaining a
MATLAB license.  At least it does in my business or in the large corporations
and universities that most of those original colleagues remain.  So it comes
down to preference.

Now you might ask (and a fair question it is!) why did I wait until this year to
join the octave development effort?  The relative sophistication of octave gave
me the impression that there must be a small army of people working on the
source and I couldn't imagine any way that I would be able to contribute. 
You should imagine my surprise when I realized that there the development
community consists of a shockingly small number of people, none of whom
seem to be computer geeks that spend all night writing code just for the
sake of writing code.

I think it's just a consequence of the 17 months gap between the two

major releases. A lot of new features released at the same time.

  

That could very well be.  Since I have only been involved for a few months,
I can't really comment.  I do think 17 months is a very long time.  Twelve
months seems like a long time.  Six months between major releases seems
awfully short.

Well, in fact we've been in the "look fur bugs" state since the end of
February or so. People could get as involved as they pleased. It seems
the start of the RC cycle excited more testing. But I think it should
really be only for tuning, and two weeks is close to the maximum time
I'm willing to spend on it.
  

Yes, everybody could be doing that since February.

I have only been on this list since early this year (or maybe late last year) but I
don't remember anybody saying "OK folks, here is the next major release.  Everybody
try to spend a few hours running their favorite code and try to find bugs".

There is an enormous difference between a positive request for help and just
expecting folks to know that something needs to be done.  This is not a criticism.
This development effort doesn't have anything like a project manager and I get
the strong impression that most folks on this list don't have that kind of experience
anyway.  And, probably, those that do would be reluctant to take THAT role on
too.

Slow down in what sense? You mean like more than 17 months between
major releases?
For me, the RC cycle is just a kind of finalization, and 2 weeks seem adequate.

  

I simply mean that an announcement is made "here is 3.2.0 RC1 -everybody
run their tests".  Then folks need time to actually run their tests.   Between
RC1 and the release was a matter of days.  Lots of folks had comments, but
almost all of them were "I can't build because of..." or "You didn't apply
patch..."  Few (no?) actual BUGS.  Certainly, *I* had time to build
only one (maybe two) of the RCs, and never had the chance to do more than
run the built-in tests and the test suite I am (slowly) building for the OOP
stuff.

I know that I keep trying to apply a commercial model in which a release
is carefully QAd before actual release.  Perhaps it is a model that simply
won't work here.  If so, ignore me.  My feelings won't be hurt.

Judging by the divergence between 3.0.x and development branch, I
think the most suitable point for branching 3.2.x was November 2008,
but I was outvoted, because most people seemed to want OOP in 3.2.
That means 10 months since 3.0.0, so calculate for yourself.

  

This surprises me.  When I got involved, sometime after November 2008,
someone stated very clearly that "I think John has done everything on the
OOP that he intends to do".  The OOP facilities at that time were solid,
just didn't have the inheritance features.  I only remember one other
statement, just after my first patch (that I stated should NOT go into 3.2),
John said he wanted it to be there.  At that point, there was a broken
version of inheritance in place.  It would have been better to release
before integrating than to release with broken features.

Personally, (in hindsight) I would have preferred a release around
the first of the year with the original OOP stuff and then a release in,
say, August or September with a a more complete and tested version
of the full OOP.  Then another one a few months after that with the
classdef stuff integrated and tested.  Of course, I am only talking
about one feature set.  I have no sense whatever about the overall
plan for other new features.

My contributions took months, but were really minor.  I did hold the
release up for a week or two right at the very end (actually, I REQUESTED
that we hold up for a week or two), but it was for a couple of quick but
very important items - important, given that everything else was in place.

Of course, I have found bugs since, but that is another issue.

Bob