Re: OCL package 1.0.0 released

[Matthias W. Klein]

> welcome on board, and sorry for the delay -- the subject of this
> thread could have been a bit more to the point.

Hi Olaf,

thanks for introducing me into the team. - I had issued a first message
on this ML with "New Octave package" in the subject line back in
April... Anyway, since then the project has picked up much interest and
supporting words which I am grateful of and has manifested, in short,
that the package is suitable for OF. No worries.

> You have now OF maintainer rights and an empty mercurial repository
> 'ocl' has been created at OF, you should be able to clone it with:
>
> hg clone ssh://address@hidden/p/octave/ocl ocl

What I have in mind is a transition time for migrating my project
from sourceforge [1] to octave forge, maintaining both repos for a
period of time and eventually disactivating (forwarding) the former
clone (while respecting consistency of names and releases at all times).

[1] https://sourceforge.net/p/octave-ocl/

So I think the OF repo should, as a next step, become a clone of the
existing SF repo; I would do this by pushing my local repo to the empty
OF repo. Will this give the correct result? I am cautious on the emtpy
repo in order not to start off wrong.

> IMHO the package is a candidate for the 'community' group. In testing,
> I explicitly request help of others (something has already been
> done). Most testing is usually to be expected when you initiate a
> release at OF.

It's controversial. I can see arguments for both 'community' and
'external': The OCL package is mainly C++ code depending on
octave core sources, which would favor a community package status. On
the other hand, OCL - especially depending on third-party OpenCL drivers
- has shown to not always be plug-and-play, which would make an external
status suitable. Currently, I am fine with 'external', but I am open for
a regrouping whenever (several of) you highly experienced guys deem it
more suitable and worth the effort.

> - As long as there is no release at OF, it is still time to
>   re-consider the name of the package at OF. Is the corresponding
>   Matlab package named the same?

The 'parallel' toolbox of Matlab offers support only for CUDA using
NVidia hardware. 'parallel' for octave is taken, and given the different
dependencies I would NOT suggest merging.

I also hold a copyright disclaimer signed by my employer referring to
"ocl" as the package's name (I have developed the package privately, but
also use it at work). Changing the package name would require me to go
through this process again... Let me avoid this.

> - Please study the directives for maintainers at our web page. You
>   should add a Makefile at the root level of your package, with
>   targets for releases and so on. This could point into the respective
>   existing targets of your src/Makefile, but that's not usual. If you
>   like, you can use (modifiy) the template root level Makefile from
>   our web-page.

Many of the directives have been familiar to me for the project layout.
So far I have, nevertheless, chosen a somewhat uncommon directory
structure in the repo. This is mostly due to the fact that, for
the usual repeated incremental code developing and testing, I am using
'make' for partial rebuilts. However, I made sure that 'make dist'
creates the correct installable release tarball. Other aspects can be
discussed with interested collaborators.

> - I'm a bit astonished that a package heavily tied to Octave internals
>   and external C-code (?) works without a configure script.

This is due to the fact, frankly, that I am mostly ignorant of autoconf
tools in practice. I know how to read and write Makefiles, but not
configure scripts. The ocl project might benefit substantially from a
collaborator familiar with the autoconf toolchain!

Best,
Matt