Re: policy for release branch

[Jaroslav Hajek]

On Sat, Jun 13, 2009 at 9:06 PM, Robert T.
Short<address@hidden> wrote:
> 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.
>

Yeah, but they won't. That's the main point. Octave does and will
always contain cool stuff Matlab does not, because it's much more open
to new ideas than Matlab. This is why Octave contains all of my
improvements and Matlab doesn't. How could I have got those into
Matlab?
As a side note, I suspect (but no proofs, of course) that certain
stuff may be possibly much harder to implement in Matlab, as Octave is
programmed in C++, while Matlab is, I think, mostly in C. For
instance, I always wondered why Matlab (unlike Octave 3.2) does not
use lazy copies for contiguous array slices. Maybe they just don't
care, but maybe it would require massive code changes.

> 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.

:) I don't need a proof Mathworks has a lot of money. So what? In EU,
I couldn't patent most of my ideas for Octave even if I wanted to. I
could probably do so in the US (like "method for fast multidimensional
array indexing"), but I surely don't want to - software patents are a
nonsense.

> 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.

No, that's actually a misunderstanding. Quoting JWE, Octave is a
community project, not a product. Products have producers and
consumers. Octave does not - it has contributors and "vanilla users".

> 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.

The mission of Octave is to suit the Octave community. Speaking for
myself, I find it very successful.

> 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.

And conversely, a number of my classmates and fellow students moved
away from Windows to GNU, FreeBSD and others. And many new are doing
so. Usually this includes a turn away from software like Matlab (often
pirated).

> 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.

Yes. As a thought experiment, imagine the money for all the licenses
your colleagues spent being instead invested into Octave development.
Would they get the same results? Of course this is just a theory.

But there's more: IMHO, actually the "improve your own tools" is what
attracts a lot of newcomers to free software. With the traditional
commercial software, like Matlab, you're pushed into the consumer
role: We (Mathworks) make the software, you use it. We implement the
algorithms, you use them to do your job. You must profit from your
job, because you need to pay for the software. Everyone's happy.

Fortunately, for many people it's not just about cost effectiveness
and "get the job done". Or, to put it in another way, buying Matlab is
certainly a good investment that will help you do your job more
efficiently. But joining the Octave community and helping improve it
is also investment into yourself, and in the long term, that's
unpayable.
I have learned an awful lot of stuff since I joined Octave, and I do
not remotely doubt that if I stayed with Matlab, I would know much
less.

> 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.
>

Why I joined? Because I wanted a platform to develop some packages
(OctGPR, NLWing2, now part of OctaveForge). Matlab was of course a
choice, but it was very expensive and I wanted to use the software on
a cluster, often running multiple copies at the same time. Octave had
no restrictions. Matlab's command line was also poor compared to
Octave's (readline). I needed the command line, because I wanted to
run it remotely on the cluster using ssh.
But the main advantage was the package system using "pkg" and the C++
interfaces (MEX really sucks).
Of course, there were a lot of negatives I disliked, mostly
performance issues. But realizing that it's free software and the
source is open, I went ahead and tried to fix the problem rather than
just complaining. I was very poor at C++ at that time, yet I managed
it eventually, sent the fix, John responded with a lot of criticism, I
updated and sent again,... and eventually, the problem was fixed. I
was amazed. Just like that, I suddenly had a better tool to work with,
and I even learned how to work with patches in the process. And I
contributed to Octave, winning an eternal glory :) I realized this is
something Matlab can never offer to me. Not even if it was free (as in
beer. yeah, it wouldn't be hard to get a pirate copy, if I wanted to).

> 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".

for example
http://www.nabble.com/feature-freeze-for-3.2-release--td22046008.html

> 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.

What would such a project manager do?

> 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.

There were more than 40 bug fixes after the branch point but before the release.

> 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.

And who says you were supposed to do more?

> 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.

Unfortunately, I have an evil, twisted mind, so I don't merely ignore
people when I disagree with them. Instead, I argue with them. So
better watch your feelings anyway, just in case.

> 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.

We *always* release with broken (buggy) features, and we did so even for 3.2.0.

> 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.

Well, that was still before the RC cycle. I stated clearly that when
the RC cycle started, I wanted it finished in a limited time, unless a
very serious problem appears. Just a finishing process. If you (or
anyone else) think you can do better, I don't insist on keeping the
release manager role.

-- 
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz