Revert mass exodus of statistics functions

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Revert mass exodus of statistics functions

Carnë Draug
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.

Carnë

Reply | Threaded
Open this post in threaded view
|

Re: Revert mass exodus of statistics functions

Rik-4
On 03/22/2018 09:00 AM, [hidden email] wrote:
Subject:
Revert mass exodus of statistics functions
From:
Carnë Draug [hidden email]
Date:
03/22/2018 08:38 AM
To:
octave maintainers mailing list [hidden email]
List-Post:
[hidden email]
Content-Transfer-Encoding:
quoted-printable
Precedence:
list
MIME-Version:
1.0
Message-ID:
[hidden email]
Content-Type:
text/plain; charset="UTF-8"
Message:
2

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?
If this is a 6-week problem then I would prefer to just suffer through it.  Even when statistics move back in to core they will still be a package.  I don't think it hurts to start training those users who want all of these functions to put 'pkg load statistics' in their .octaverc file.

--Rik

Reply | Threaded
Open this post in threaded view
|

Re: Revert mass exodus of statistics functions

Juan Pablo Carbajal-2
In reply to this post by Carnë Draug
On Thu, Mar 22, 2018 at 4:38 PM, Carnë Draug <[hidden email]> wrote:

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

Shouldn't we first agree on the actual procedure for moving
function/packages. I think going unilateral here might disrupt the
small OF community that's already there. I suggest caution.
Will the 'core' packages will be a OF category?

Reply | Threaded
Open this post in threaded view
|

Re: Revert mass exodus of statistics functions

Carnë Draug
In reply to this post by Rik-4
On 22 March 2018 at 16:29, Rik <[hidden email]> wrote:

>
> On 03/22/2018 09:00 AM, [hidden email] wrote:
>
> Subject:
> Revert mass exodus of statistics functions
> From:
> Carnë Draug <[hidden email]>
>
>> 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.

And there shouldn't even be a need for a synced release of the forge
statistics package.  Because the package aims at supporting older
octave versions, the new release will still work with 4.2.  The reason
why a new statistics package has not been done cannot be because it's
waiting on a 4.4 release.

Also, what happens with mxe-octave?  My understanding is that it comes
with forge packages.  However, because there hasn't been a statistic
package with those functions so the mxe octave release for 4.4 will
come with a statistics package that will not include the removed
functions.

So a new release of the statistics package should be done first.

> If this is a 6-week problem then I would prefer to just suffer
> through it.  Even when statistics move back in to core they will
> still be a package.  I don't think it hurts to start training those
> users who want all of these functions to put 'pkg load statistics'
> in their .octaverc file.

But what about those functions that do not end up in the core
statistics package (matlab incompatible functions)?  Users of such
functions will now have to load the statistics package and in 9
months, when 5.0 gets released, they will have to do something else
which we don't even know what it is yet.  But maybe a core package
will take longer to happen, and maybe there's not even users of those
functions.

Carnë

Reply | Threaded
Open this post in threaded view
|

Re: Revert mass exodus of statistics functions

Juan Pablo Carbajal-2
On Thu, Mar 29, 2018 at 10:36 PM, Carnë Draug <[hidden email]> wrote:

> On 22 March 2018 at 16:29, Rik <[hidden email]> wrote:
>>
>> On 03/22/2018 09:00 AM, [hidden email] wrote:
>>
>> Subject:
>> Revert mass exodus of statistics functions
>> From:
>> Carnë Draug <[hidden email]>
>>
>>> 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