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

[Carnë Draug]

On 29 January 2014 05:41, c. <address@hidden> wrote:
>
> On 29 Jan 2014, at 00:41, Carnë Draug <address@hidden> wrote:
>
>> Is there any way to move a file between two
>> different hg repositories, while keeping its history?
>
> While I'm sure our HG guru will find a trick to accomplish this task, I can't 
> help but
> point out how this issue shows why your approach to managing the package 
> contents is
> inconsistent:
>
> - On the one hand, you created separate repositories for each package to
>   make their maintainance more indepent and decentralized, and to allow even
>   development to happen outside Octave Forge as in ltfat.
>
> - On the other hand you keep moving around functions from one place to another
>   and making "interventions" on their contents as if OctaveForge were one 
> single
>   package, and you its maintainer.

Even packages developed elsewhere (ltfat is not the only one) must
have a clone in the the Octave Forge website, and have it up to date
at time of release. That is why, for example, the NaN and tsa packages
took almost 1 year to release.

I did not move just functions. I merged entire unmaintained packages
around because we had (probably still have) too many packages. One
single package is too little, but the current amount of packages is
too high. There was also move of a few functions, I remember
specifically a few functions from miscellaneous being moved to IO
(with permission from the IO package maintainer), but do you disagree
with any of them?

> So if we really want to go back to something closer to the "monolithic" 
> distribution approach,
> which I actually don't but I keep seeing you drifting towards that with time, 
> then I suggest to
> do the following:
>
> - change the name of "miscellaneous" to "cruft" [1] and use it as a collector 
> for all leftovers
>   from deprecated/unmaintained/buggy/dodgy packages that we don't feel like 
> throwing away
>   completely but we don't expect many users to actually need in real life.
>
>   That would include stuff like @dict, of which none of us actually 
> understands the purpose,
>   or "solvesudoku" which is a cool programming example but not really meant 
> for everyday use.
>
>   I would make it a strict rule that NO package should ever be made dependent 
> on "cruft".
>
> - change the name of "general" to "standard-additions" [2] and use it for any 
> useful little functions
>   that do not belong into any other package but are useful for everyday use 
> or are dependencies for
>   other packages.
>
>   This would include stuff like @InputParser or physicalconstants.
>
> What do you think?

The problem is in the decision of what would be "standard-addition"
and "cruft". This is rather a matter of needs, more than of opinion.
And we can't for sure, be throwing functions back and forth between
these two packages, as we will, if we base this on their level of
maintenance and bugginess.

Here's what I will suggest, which is what I do. When adding a new
function that would go into any of these two packages, look into
scripts/miscellaneous and scripts/general of Octave core, and decide
in which of these two it would fit best. Then add to the corresponding
package. And if a function is really useful, then suggest them to go
into core. Would not be the first that it happens.

My opinion on these two packages, is, had they never been created in
the first place, to have them as one, or, had we something such as
CPAN, to have each function as a separate package. But neither is
true, so here we are. If we ever get our CPAN working, those they will
be the first out of Octave Forge, but until then, I don't see a
reasonable solution.

Carnë