octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: c.
Subject: Re: very small packages - merge into general/miscelleneous or move into core
Date: Wed, 29 Jan 2014 06:41:42 +0100

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.

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?

c.


[1] Other names would also be possible but as we have liboctave/cruft in core 
it would 
    make sense to me to use the same in forge.

[2] I'm notoriously not good at choosing names, so feel free to propose a 
different one.
    This one has an history though as it was the name of the an extra disk that 
came with
    some versions of MacOS Classic, containing all stuff that was not essential 
for the 
    system but that anyone with sufficient disk space was expected to install.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]