Re: Revert mass exodus of statistics functions

[Juan Pablo Carbajal]

On Thu, Mar 29, 2018 at 10:36 PM, Carnë Draug <address@hidden> wrote:
> On 22 March 2018 at 16:29, Rik <address@hidden> wrote:
>>
>> On 03/22/2018 09:00 AM, address@hidden wrote:
>>
>> Subject:
>> Revert mass exodus of statistics functions
>> From:
>> Carnë Draug <address@hidden>
>>
>>> For the upcoming Octave version, we moved a bunch of Octave functions
>>> from core to the statistics Forge package.  We are also now planning
>>> on having a statistics package as part of core.
>>>
>>> This is already causing trouble because we don't a have a release of
>>> the forge package to cover the removed functions.  What if we revert
>>> that change and instead move the functions to the core package for 4.6
>>> release?  This would be less disruption to the end user and avoid the
>>> complications on the current forge package.
>>>
>>
>> How long is this going to be an issue?  If 4.4 is released won't
>> there be an accompanying update and release of the statistics
>> package?
>
> Well, someone will have to do it and I don't see anyone working on
> preparing it.

Maybe you should stop standing on your assumptions and actually start
looking around.

I have been insisting in a release since before OctConf, and have been
putting some time on it...until I got put off by the new extra
complications in the build, check and installation process.

What I am trying to say is:

1. There is people working on it: I count me and Olaf. We are not
aligned in our effort, that's surely an issue.

2. This whole issue showed us once again how we are lacking a mission
for octave forge (and a vision, where are we going?). I always vouched
for simplicity (this put me at odds with Carne before and now with
Olaf), because I see the lack of man-power to keep up unrealistic high
standards, and because we scare the contributors who do not see
themselves as "developers". We need the commitment of other type of
"developer" and we need to keep things simple because we lack
man-power. Just to be clear, with simple I do not mean shitty, but the
best we can do when we factor in our resources (the current and the
expected future ones).

I did not understand exactly why the functions were moved out from
core, (as Olaf mentioned) I always understood we wanted to go the
other way around: move things from OF to core when they get mature
enough (ML compatibility, etc...).
I would say we roll back and put things back to core. This way we
avoid the new complexities in OF, the problem with the users, and we
fulfill the expectations of the users jwe was worried about: those who
expect certain functions loaded by default.

Now comes the issue of responsibility for maintenance: if a function
goes to core, is it only responsibility of core developers? I say no
(I mean, not automatically and not expected, but we shouldn't
interfere on what the dev considers his responsibility), if the
function moved from OF to core, then the OF parent package has a
maintainer and we should keep that link. At the end of the day the
folder in core is called just like the OF package.It is obvious
enough, let's keep it that way.

At the same time, why move things around anyways. It is very easy to
install an OF package. If users want certain functions we need to:

1. Explain very clear how you load a package by default (we can even
provide a solution rc file)
2. Improve our tools for users to search for functions in OF packages

Sorry for my direct language, I am not trying to insult anyone here.

My two cents.

JPi