Re: very small packages - merge into general/miscelleneous or move into core

[c.]

Hi Thomas,

On 12 Jan 2014, at 14:12, Thomas Weber <address@hidden> wrote:

> Why should a large package be any more different to manage than a
> smaller one?

There is a large number of reasons why this is the case, the main two
that come immediately to mind are the following:

1) While code maintainance effort is not exactly directly proportional
to the number of code lines, there does exist a strong positive correletion
between the two quantities.

2) The larger the number of completely unrelated functions contained in
a package is, the smaller the probability to find a maintainer or a team of
maintainers who are able to deal with all of them will become.

> One large Forge package is too much, but the current
> situation where you have packages with 3 .m files is also clearly not a
> good solution.


Why? 

If there is an interesting and useful functionality that can be provided
by one single function, like for example physical_constants, why shouldn't
users be offered the convenience of installing it via "pkg install -forge"?


> If you have a particular problem, you ask on the list.

Yes, I do. But the vast majority of Octave users don't.

> With 100+
> packages, the idea that you can find a solution to a specific problem by
> looking at the package name is bound to fail right from the start.

I don't think the package name should be used for that purpose.
I think that purpose is better served by the package description pages.

From here I can guess that if I have to solve a PDE problem bim might have the 
functions I need:

 http://octave.sourceforge.net/bim/index.html

While this won't help me find where InputParser is:
 
 http://octave.sourceforge.net/general/overview.html

Organizing the package list hierarchically or adding keywords to 
packages and the ability to filter package lists by keyword would 
also make this task much easier. 

But adding new features to the Octave Forge website has been considered useless
as the release of Agora was supposedly "imminent". It has been "imminent" for 
more than two years now.

> Case in point: seqreverse.m from bioinfo. If you look at the first test
> case, should't this functionality be part of the package strings?


I am not maintainig neither "bioinfo" nor "strings", my opinion about
whether that function should into either of those two packages is therefore 
irrelevant.

I can tell you, though, that I wouldn't want that to go in any package 
maintained
by myself and that I do not need it so I'd rather not have it into any package
I usually install.


Packages should be collections of strictly related functions that are useful
for solving a well delimited set of problems. 
It should be the sole responsability of the package author(s)/maintainer(s) to
decide what should and should not go into them. If the author of bioinfo felt
that, to fullfil the task for which that package is intended, the function  
"seqreverse.m" is needed, then that function does belong there.

If you believe it could be beneficial to move that function to a different 
package
you should discuss this with the origin/destination package maintainer(s). 

> You don't hold back a release just because not all bugs are fixed. This
> has never been the case. A newer release should be "better" than the
> previous version, not "flawless".


My example was much less abstract than you may think.

Some of the functions in "strings" and "struct" have docstrings in plain text 
form.
As shown by the recent discussion about the release of the "mpi" package 

 1) Currently "generate_html" will not work well for that kind of functions
    on a system where texinfo 5 is installed.

 2) Carnë will (understandably) not accept a package release if the html docs
    are not properly generated.

So if I want to release an improved version of parcellfun, I will need to fix
the docstrings of those functions which I know nothing about.
This will simply not happen.


That said, I understand that our different points of view are strongly 
influenced by the fact that you are working on packaging Octave Forge 
packages for Debian, while I am more involved in package development 
and maintainance.

Of course both aspects have to be considered, but to do so requires keeping
an open mind on both sides.

So, to make the discussion about this less based on opinions and more based on 
data, 
maybe we should check how we compare with other similar projects.

Candidates are:

PyPI for Python: https://pypi.python.org/pypi
Scipy-central for Scipy: http://scipy-central.org/
CPAN for PERL: http://www.cpan.org/
CTAN for TeX: http://www.ctan.org/

Do you know a way to count the packages in those repositories and the number of 
files in each package?

These are the info that are immediately available:

PyPI says they host 38791 packages.
CTAN says they have 4623 packages by 2158 au­thors.
I counted about 80 packages in the Scipy-central archive.

Can you suggest a way to collect the remaining data?

c.