Re: Requirements for releasing the STK toolbox as an Octave forge package ?

[c.]

On 10 Feb 2014, at 09:09, Julien Bect <address@hidden> wrote:

> Dear Octave forge maintainers,
> 
> A while ago I announced a new release of the STK, version 2.1.0, a toolbox 
> developped and maintained by my colleague Emmanuel Vazquz and myself :
> 
> http://octave.1599824.n4.nabble.com/STK-2-1-0-released-td4660018.html

Looks like a very useful tool!

> I would love to see our toolbox distributed as an Octave forge package... 
> what would be the requirements for that ?

Essentially you should just ask to create a mercurial repository on Octave 
Forge for your package.

> Our project is currently hosted on Sourceforge 
> (http://sourceforge.net/projects/kriging) and we want to keep it that way, so 
> I'm thinking of something like the LTFAT, which is distributed as an Octave 
> forge package but hosted on a separate repository.

yes, that should be possible as long as you also clone your repository in 
Octave Forge.
But can you explain why you care to have double distribution?

> I have started to write a Python script that prepares a tar.gz with all the 
> required files for an Octave package (DESCRIPTION, PKG_ADD, PKG_DEL and so 
> on). It is not finished yet, but already produces a valid package that can be 
> installed using Octave's pkg command :
> 
> http://sourceforge.net/p/kriging/code/HEAD/tree/trunk/admin/make_octave_package.py

I think that is at least the third such script that has been created,
IMHO it would be better to have that written in Octave language though ...

> Our documentation is currently in plain text format, but I can wrap it in 
> @deftypefn + @verbatim texinfo environments (again, as done in the Octave 
> package release of the LTFAT package).

that's actually not even necessary, we have other packages that use plain text 
docstrings, usually when they want to keep matlab compatibility.

> Would there be any other requirement for our toolbox to be distributed as an 
> octave forge package ?

maybe you could also check whether your package has 
conflicts/overlaps/redundancies with respect to other existing packages.

> @++
> Julien

c.