Re: regarding location of Matlab compatible polygon functions

[Carnë Draug]

On 10 April 2016 at 23:22, Philip Nienhuis <address@hidden> wrote:
> Carnë Draug wrote:
>>
>> No, you got my argument wrong.  The core of my argument is not that Matlab
>> users would expect this organization (that is just an extra).  My argument
>> is that Matlab organization is good enough and following it means one less
>> thing to argue about.
>
>
> Your first argument ("Matlab ... good enough") is, well, a good opinion.
>
> But that second argument, "one less thing to argue about", can also be
> perceived as a way to simply evade discussion.

And it is.  It has always been.  This is exactly how it should be perceived
and I thought it was pretty clear from the start.  Other people may have
other reasons to want it.  I thought mine was clear from the start.

Following that organization means we don't discuss about it.  It means we
don't discuss breaking backwards compatibility about moving them between
packages some other day (because a package becomes unmaintained or a new
package has been created that is more specific to those functions).  And
means not opening the Pandora box for all other functions in other packages
that are still Matlab compatible.

> Extending that a little, what's the whole point of Octave when "Matlab is
> good enough" ? If all of us here just stop with Octave we'd be free of any
> arguing whatsoever.

If you are quoting me, quote the whole sentence.  I said "Matlab organization
is good enough" and this in the context of which toolboxes each function goes.
So there is loads of places where one can improve, a very important one being
writing an implementation that is free software.


> [...]
> Octave isn't plagued by commercial business models. I think that is a big
> benefit of, and for, OSS, because it allows small and dedicated
> toolboxes/packages that can be maintained by one or only a few volunteers.
> Small and dedicated packages also help keeping the namespace within
> reasonable limits.

Two issues with this argument:

  1. The premise that smaller packages are better is flawed.  Indeed,
    4 years ago we decided exactly the opposite, that small packages were
    too much or a maintenance burden.  That's the reason why some small
    packages were merged into others.  It basically boils down to the cost
    of making a release and limited number of package maintainers which led
    to changes never being release.

  2. Even if the premise was true, the geometry package is already among
    the largest packages in Octave Forge.

The ideal size of a package for maintenance is a completely different
issue and there's no need to mix it in this discussion.  And it's not
simple either, neither of extremes is ideal (single function packages
or all functions in one package -- such as monolithic Octave Forge
releases).

Carnë