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

[Thomas Weber]

Hi, 

On Sun, Jan 12, 2014 at 09:44:18AM +0100, c. wrote:
> I am already a bit confused about what "miscallaneous"
> and "general" are meant to be, and I'm afraid that
> if you continue adding functions to them they'll keep 
> growing and eventually become unmanageable.

Why should a large package be any more different to manage than a
smaller one? 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.

> 1) Can you explain in detail what these two packages are, 
>    i.e. a deterministic criterion to identify functions that 
>    should go into each of them?
>    Let's say I'm not familiar with the contents of OF and I 
>    am looking for some function that solves a particular 
>    problem I have, e.g. I have to apply the same function 
>    to all the elements of a large cell-arry and want to do 
>    so in parallel, what should lead me to find out that the 
>    solution to my problem is in the "general" package? why 
>    isn't it in "miscellaneous"?

If you have a particular problem, you ask on the list. 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.
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?

> 2) Let's say I found out (most likely by asking on the list) 
>    that I need "parcellfun" and therefore I installed "general". 
>    What makes you think I probably also need the functions currently 
>    in "strings" or "struct"? 
>    Or, to use an example that affects me directly, what makes you 
>    think that if I like to have a database of common physical constants
>    I should also be interested in solving sudoku or "game of life"?

Packages are meant as a way to manage the functions included in them,
not for users to pick just the few functions they need and not a single
one more.
Even if you process strings a lot, it is still perfectly possible that
you do not need some functions from the strings package. Should we split
it up?

> 3) Now consider I am a developer and I found and possibly fixed
>    a bug in "parcellfun". I want to make a release to make this
>    fix available, but there are problems whith other functions
>    in the same package which I don't really know anything about 
>    and they have problems that make the release unpractical. 
>    Should I hold back the release until those are fixed? Why? 

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". 

> Finally consider that the "struct" package does have an official 
> maintainer, "general" and "miscellaneous" don't. Do you think we need
> more packages with a specified maintainer or do we need less?

We need less packages. Do you think that it is a sensible use of time
for maintainers of binary installers to check 100+ packages for what to
include? Is is sensible for end users to browse such a list and look for
a solution to a problem? Having even 100 .m files on your hard disk that
you never use is a tiny price if you save one hour while installing and
updating packages.

        Thomas