OF and packages (devs please read)

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

OF and packages (devs please read)

JuanPi
Hello all,

Since already quite a few years Carnë has been doing an excellent job
with Octave-Forge. Therefore his opinion has an important weight and
should be considered.

In a recent, not so friendly, discussion in our IRC channel, he
brought the point forward that, maybe, functions that are not popular
should be removed. This, plus the periodical move to core (also based
on some measure of popularity), would eventually make some packages
empty (take a look at pkg general at the moment).

Now, popularity is hard to measure, specially if we are not in the
field where the functions apply. Removing functions from packages
because some of us deem it useless might be uncomfortable for some
users (nothing that can't be solved with a copy of the function in a
local folder and an addpath to it), so I think it should be done with
care.

On the other hand, OF needs considerable time to maintain (and can
burn out important contributors), hence trying to reduce it size
sounds reasonable.

What measures of popularity would you suggest?
and
How you would go with removing packages?

--
JuanPi Carbajal
Public GnuPG key: 9C5B72BF
-----
The end of funding: "Many researchers were caught up in a web of
increasing exaggeration."
- Hans Moravec

Reply | Threaded
Open this post in threaded view
|

Re: OF and packages (devs please read)

Oliver Heimlich
Hello,

I am quite new to the Octave community, but have an opinion nonetheless ;-)


On 05.05.2015 22:12, JuanPi wrote:
> On the other hand, OF needs considerable time to maintain (and can
> burn out important contributors), hence trying to reduce it size
> sounds reasonable.

This is the most important point and I want to comment it first. If we
do not have enough resources, we must drop unmaintained stuff.
Especially when it starts to make problems. Otherwise users would see a
broken product and get a bad overall impression.

For example, we have tried to evaluate the current Octave Forge packages
for compatibility with MS Windows and the 4.0 release [1]. Many showed
up broken during the first attempt and most have already been handled
one way or the other. However, there is a scary number of packages
marked as “unknown,” because of no/few unit tests.

It is impossible to maintain all these packages without enough resources.

However, this topic has not been addressed in the recent past on the
mailing list. Maybe I am not up to date. What kind of help is needed?


> Since already quite a few years Carnë has been doing an excellent job
> with Octave-Forge. Therefore his opinion has an important weight and
> should be considered.

Yes, Carnë does an excellent job. AFAIK, he handles the package
releases, the website updates, users, and also finds time to work on
various packages.

> In a recent, not so friendly, discussion in our IRC channel, he
> brought the point forward that, maybe, functions that are not popular
> should be removed. This, plus the periodical move to core (also based
> on some measure of popularity), would eventually make some packages
> empty (take a look at pkg general at the moment).

What do you mean by “popular” functions? Functions that are actively
maintained by somebody, or functions that are actually applied by Octave
users?

Either way, unpopular functions contain “dead code” or “unused features”
and, if tests are missing, are very likely to be broken some day. In a
situation where we have more packages than we can handle, I can
understand that we should either get rid of it or find a way to maintain
it easily (with appropriate tests for example).

Packages called “general” or “miscellaneous” have a special problem.
They are a collection of various function files that didn't fit
elsewhere. On the one side some of these functions could potentially be
merged into core one day. On the other side some other packages depend
on them. Thus, they have an inevitable content fluctuation with
dependencies in both directions.

Packages that follow a certain topic, e. g., java, image, database, are
more likely to either be merged into core as a whole (java) or are kept
separate as an easy separation of concerns (image).

> Now, popularity is hard to measure, specially if we are not in the
> field where the functions apply. Removing functions from packages
> because some of us deem it useless might be uncomfortable for some
> users (nothing that can't be solved with a copy of the function in a
> local folder and an addpath to it), so I think it should be done with
> care.

I don't think we can measure the popularity of single functions. Why do
you want to remove the functions in the first place?

  - Merged to core? Try to maintain a shadowing function in the package,
which shortcuts to builtin(...) in newer versions. Eventually remove it
from the package.

  - Broken? Try to fix it. If that's not possible, remove it. Nobody
needs a broken function.

  - Unclear status? Write unit tests.

  - Compatibility issues? Try to resolve by renaming the function.

  - Unmaintainable? Depends on the problem.

What is the state of Agora Octave? Removed single functions could be
“buried” there, still being publically available (unless they have been
moved to core).

> What measures of popularity would you suggest?
> and
> How you would go with removing packages?

First, I need to know why the popularity measure is needed (see above).

We should drop packages (move them to the unmaintained section) that
can't be maintained anymore and are known to cause problems (either on
the user or on the developer side). They can then be installed “at your
own risk” and maybe will find a maintainer to be brought to live again.

Oliver


[1]
http://wiki.octave.org/Octave-Forge#GNU_Octave_4.0_compatibility_assessment

Reply | Threaded
Open this post in threaded view
|

Re: OF and packages (devs please read)

Carnë Draug
In reply to this post by JuanPi
On 5 May 2015 at 21:12, JuanPi <[hidden email]> wrote:

> Hello all,
>
> Since already quite a few years Carnë has been doing an excellent job
> with Octave-Forge. Therefore his opinion has an important weight and
> should be considered.
>
> In a recent, not so friendly, discussion in our IRC channel, he
> brought the point forward that, maybe, functions that are not popular
> should be removed. This, plus the periodical move to core (also based
> on some measure of popularity), would eventually make some packages
> empty (take a look at pkg general at the moment).
>
> Now, popularity is hard to measure, specially if we are not in the
> field where the functions apply. Removing functions from packages
> because some of us deem it useless might be uncomfortable for some
> users (nothing that can't be solved with a copy of the function in a
> local folder and an addpath to it), so I think it should be done with
> care.
>
> On the other hand, OF needs considerable time to maintain (and can
> burn out important contributors), hence trying to reduce it size
> sounds reasonable.
>
> What measures of popularity would you suggest?
> and
> How you would go with removing packages?

This is a quite bad wording of my opinion.  This is on the context of the
general package.  Packages have a category, they provide extra functionality
for a specific aim.  The language core provides general functionalities.
This makes having a package for general stuff pointless (on the other hand,
we also don't want to have one package for each funtion like happened before
which was a pain to maintain, so some balance is required).

Let's remember that OF appeared in a time where Octave development was
quite slow, when few had commit rights to core.  OF was needed to speed
this, to attract developers.  This is no longer true.  Development of core
is quite fast now.  There's many developers constantly acting on bug and
patch reports.  There's no need for a "development bed" of functions in OF
if the long term plan is to move them to core.

Also, that OF was once a monolithic project, its main part matching
the directories in Octave core "scripts/".  Functions developed here
would move to the respective place in core.  Then we made a package out
of each directory.  We wouldn't even have these packages if OF started
development as individual packages.

Looking at the history of general, it had many functions, and many have been
removed.  They are always removed because they move into core or into some
other package.  No function has been removed after deciding that including
in the OF was the wrong thing.

So yeah, I want to pull the plug on this package.  Other packages are only
dependent on it because of inputParser which has has now been moved to core.
There's only a few functions on the package now.  Someone needs to makes a
case for them, show that they are general and good enough to be integrated
into Octave core.

We have done this before.  These packages are not removed, they reside at
the bottom of the OF package list, the unmaintained section:

  http://octave.sourceforge.net/packages.php#unmaintained

The repositories for all of those packages are still kept with full
commit history as well as the release tarballs.  Nothing has been lost.


---


In the great view of things, my worry is not so much about whether a
function or a package is useful, my worry is if a package is maintained
and provides a good image of the Octave Forge project.  Packing up a
directory into a tarball and upload it to the release tracker is easy.
Actually making a package release is hard work.

Would be nice if we stopped faking that packages like general (and
miscellaneous since we are at it) are maintained.  The authors of their
functions are gone from the community.  They have very few tests, not
enough to assess the function actually works correctly (when they
have test at all).  Some don't even have documentation and we have no idea
how they work.  How can we really maintain them?  How can anyone expect us
to do so?  I don't expect anyone to step up and do it.

There's more packages like this.

Ans these packages get released because someone else adds a new function to
them.  Or because it doesn't build anymore.  Doesn't build with the new
version Octave?  Only the minimum fix is done so it builds again.  The only
objective is that the package installs again. So its other functions, the
dependencies of the actually maintained packages can be used.

The package may have been untouched for 1 year, have all sort of
other compatibility problems, but a new release is made anyway.
A new release, a new number version, a recent release date.  This gives
the user the impression that the package is working and is maintained.
These are lies.  No thought goes on making releases of these packages.
I know that with GPL we provide no warranties.  But come on!  When someone
makes a package release, they should have an idea of what they are doing.

I don't understand how anyone can just tarball the directory of a package
and try to make a release of it.  Even after all this years I'm still not
comfortable with all the functions in the image package.

And honestly, I am really tired of making those releases.  More than once,
tarballs have been uploaded for release that didn't even had the configure
script.  Whoever prepared them didn't even know that the package required
the maintainer to run autoconf (or bootstrap or autogen) first.  Note that
this is not forgetting.  This is not knowing.

We don't need anyone to step up and make package of these packages.  I can
make that in a fraction of the time it takes me to review such package
releases.  We need someone to actually maintain those packages.  And unless
is someone that actually likes the problems the package solves, or is
actively working on it, then that person is not the right person.

Carnë

Reply | Threaded
Open this post in threaded view
|

Re: OF and packages (devs please read)

Colin Macdonald
On 07/05/15 22:09, Carnë Draug wrote:
>   Packages have a category, they provide extra functionality
> for a specific aim.  The language core provides general functionalities.
> This makes having a package for general stuff pointless

+1  I wrote my own dirac.m and heaviside.m and proposed them for core
because it honestly never occurred to me to look in something called
"general" or "specfun" or "miscellaneous"!

But I know exactly where to go for *image* processing or *interval*
arithmetic.

Colin


Reply | Threaded
Open this post in threaded view
|

Re: OF and packages (devs please read)

Jordi Gutiérrez Hermoso-2
On Thu, 2015-05-07 at 22:52 +0100, Colin Macdonald wrote:
> On 07/05/15 22:09, Carnë Draug wrote:
> >   Packages have a category, they provide extra functionality
> > for a specific aim.  The language core provides general functionalities.
> > This makes having a package for general stuff pointless
>
> +1  I wrote my own dirac.m and heaviside.m and proposed them for core
> because it honestly never occurred to me to look in something called
> "general" or "specfun" or "miscellaneous"!

At risk of preaching to the choir, I will agreee general and
miscellaneous are kind of silly, but "special functions" is a term of
art with a couple centuries of history, a history which doesn't
include functions such as multinomial coefficients nor the Dirac delta
function:

    https://en.wikipedia.org/wiki/List_of_special_functions_and_eponyms

Then again, since most Matlab or Octave users seem unaware of what
are usually considered special functions, and since the term itself is
loosely defined, I suppose it's no better than "general".



Reply | Threaded
Open this post in threaded view
|

Re: OF and packages (devs please read)

Juan Pablo Carbajal-2
On Fri, May 8, 2015 at 2:21 AM, Jordi Gutiérrez Hermoso
<[hidden email]> wrote:

> On Thu, 2015-05-07 at 22:52 +0100, Colin Macdonald wrote:
>> On 07/05/15 22:09, Carnë Draug wrote:
>> >   Packages have a category, they provide extra functionality
>> > for a specific aim.  The language core provides general functionalities.
>> > This makes having a package for general stuff pointless
>>
>> +1  I wrote my own dirac.m and heaviside.m and proposed them for core
>> because it honestly never occurred to me to look in something called
>> "general" or "specfun" or "miscellaneous"!
>
> At risk of preaching to the choir, I will agreee general and
> miscellaneous are kind of silly, but "special functions" is a term of
> art with a couple centuries of history, a history which doesn't
> include functions such as multinomial coefficients nor the Dirac delta
> function:
>
>     https://en.wikipedia.org/wiki/List_of_special_functions_and_eponyms
>
> Then again, since most Matlab or Octave users seem unaware of what
> are usually considered special functions, and since the term itself is
> loosely defined, I suppose it's no better than "general".
>
>
>
The history of multinom is complex, indeed. I think you were involved
and, if I am not wrong, combinatorics (now disappeared) was a better
place for it, but we ended up in specfun (due to comments about not
using general) ... I was quite frustrated by the lack of a converged
criteria about this ... if we do not know where functions go (mind the
*we*, everybody has its own criteria, of that I am sure) ...

I must say that I am convinced by Carnë's arguments, the criteria to
deprecate a package is whether it is maintained or not (by the
announced maintainer). However the whole discussion brings the usual
issues up:

1. *OF to provide domain specific functions*. Searching OF is
currently a pain and what is most visible to the user is the package
name, from which they try to guess what the package contains (things
like bim, ocs, tsa. Easy, right?). Being the name a big part of what
indicates where to put a function creates already a problem (the same
function can used in different fields, so it is image? or is it a
spcefun? or is it kriging? or filtering?). If there is a source for
unmaintained functions it should also be easy to search. This is the
best service we can offer to our users, let them find things easily.
Not being currently the case, that things can be found easily, putting
functions deep within a package called symbolic (e.g. in the case of
multinom) will just reduce the usability and visibility of the
function, because people who might need its functionality will not
look into a package that is about (apparently from the name) about
symbolic computations[1]. Not to mention the lots of dependencies and
functions name added to the user workspace. I said this as a user that
has been through this problem. I am sure they will be very clever
(developer friendly) solutions to this "search" issue, we got to put
ourselves in the shoes of the users, and release a little bit the
developer perspective.

2. *Time of commit as a measure of maintenance*. At some point, if the
functions provided by a package are well established, the commits to a
package will necessarily dim out and converge to commits only to solve
compatibility problems. How often do these problems emerge? I guess
better than the time or number of commits, is to check(as suggested by
Carnë): first whether the package installs or not, second whether
there are bug reports that are not being take care of. I think we need
to settled on a criteria (group one, not just one of the current OF
head) so that we can collaborate more effectively as a group and
develop automatized admin tools (like the Makefiles that have appear
lately). This also helps new users or potential package contributors.

3. *Searchable function repository*. We need to get developers for
Agora! Seriously.

[1] With time this brings the question whether the function is
popular...is it not being use because it sucks or not needed, or is it
unfindable?

Reply | Threaded
Open this post in threaded view
|

Re: OF and packages (devs please read)

Colin Macdonald
On 08/05/15 07:00, Juan Pablo Carbajal wrote:
> 2.*Time of commit as a measure of maintenance*. At some point, if the
> functions provided by a package are well established, the commits to a
> package will necessarily dim out and converge to commits only to solve
> compatibility problems. How often do these problems emerge? I guess
> better than the time or number of commits, is to check(as suggested by
> Carnë): first whether the package installs or not, second whether
> there are bug reports that are not being take care of.

third: whether it has tests and whether they still pass.