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