Re: [OctDev] license.m

[William P. Y. H. <wil...@gm...>]

On 11/28/05, Paul Kienzle <pki...@us...> wrote:
> William,
>
> Can you please post functions which implement base matlab
> function to bu...@oc....  John expressed an interest
> in having more complete coverage in time for the Octave 3.0
> release.
>
> If he does not want them or does not act on them in a
> reasonable time (e.g., six weeks) then I'm happy to
> include them in octave-forge, but I would prefer to
> give John first right of refusal (I will need reminding).
>

OK, I've posted them on bu...@oc....

> The alternative is to build infrastructure so that octave-forge
> doesn't shadow any octave functions unless we tell it to
> in the build/install scripts.  If anyone wants to tackle
> this, keep in mind that we want to support testing before
> installation, which means installing all the files we want
> to keep into a temporary build directory.  I think
> converting each subdirectory to support S=F8ren's packaging
> system (extended as necessary) is the best way to go.
>

Yes, I think this is good, because we wouldn't need to worry about old
octave-forge functions shadowing new octave functions. I think a
script can do this, and it can also help us when we want to check for
(and remove) obsolete functions in octave-forge.

I've heard about this packaging system before, but I haven't checked
it out yet. Maybe you can put a temporary "freeze" on the cvs
repository, checkout the latest version, make the changes, empty the
repository, then upload the new files?

--
William Poetra Yoga Hadisoeseno