Re: OF and packages (devs please read)

[Carnë Draug]

On 5 May 2015 at 21:12, JuanPi <address@hidden> 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ë