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

[Carnë Draug]

On 10 February 2014 11:07, Julien Bect <address@hidden> wrote:
> Le 10/02/2014 11:32, c. a écrit :
>
>> On 10 Feb 2014, at 09:09, Julien Bect <address@hidden> wrote:
>>>
>>> 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?
>
>
> STK is meant to work both with Octave and with Matlab and, for that reason,
> its primary repository is not organised as an Octave package. I would like
> to keep the current organisation, which allows to use the toolbox "in place"
> both from Octave and from Matlab, and from there generate for each release
> an Octave package for Octave users that prefer to install it using pkg.
>
> Plus, we want like to keep full control over the STK as a Sourceforge
> project (description, front page, developpers, screenshots, news, etc.).

This is perfectly fine with us. However, we do need to keep a clone of
the repository for ourselves with everything ready to prepare a
release. This is not the unpacked tarball, can be a repository with a
very different structure (like what you have now), with the script
used to create a tarball of the package that is released.

I noticed you are using svn. If you were using mercurial or git, the
distributed would be more natural. It is still possible to do it, it's
just less natural. Would probably be easier if you converted your
repository to one of them (in Octave we have a preference over
mercurial) and I can help you with that if you pop in #octave one of
these days.

>>> 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,
>
> Well, it is by no means meant to be a generic script for doing this, just
> something ad hoc that can process the specific file/folder structure of STK
> and convert it to an Octave package. But if there are other scripts out
> there from which I could take inspiration, I would be glad to have some
> pointers.

I have written such scripts before. Each project places things in
different places so it's not really feasible to write one for all
cases (a template that can be adjusted to each case would be a useful
thing but that's a completely different issue). I very much support
this type of distribution for projects that want to create packages
for both Octave and Matlab.

>>> 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.
>
> optiminterp does something that looks very much like (noiseless) kriging,
> although I haven't looked at the details.
>
> splines also has connections with kriging, since for examples spline
> smoothing with thin-plate splines can be seen as kriging with a certain
> (generalized) covariance function

We can't distribute the package if any of its function has a
conflicting name with other packages (that doesn't seem to be the case
with all your functions starting with stk_).

I saw that your package is dependent on Matlab's parallel package and
recommends the optimization package. We also have those 2 packages but
I'm not sure if they have implemented what you require from them.

Basically the basic requirements to be distributed with Octave are:
* installable in Octave via pkg
* clone of the repository with everything required to prepare the
release in our side as well
* not dependent in any non-free software
* released under a GPL compatible license

Carnë