Re: OCL package 1.0.0 released

[Matthias W. Klein]

Dear Kai, dear Juan,

thank you for giving a new jolt to the project's status.  BTW, I think
responding supportingly is never "too late" considering we all (or
almost all) do the developing besides our jobs and other private activities.

> I personally will suggest opencl as package name rather than ocl, the
> 3 extra letters make a huge difference in clarity.

As to the package name:  There are a number of packages both with long
and with short names at OF (openmpi_ext was even renamed mpi).  Clarity
is a point, but the package content is also clear from the one-line
title ("OpenCL support for GNU Octave").  I chose the name OCL over a
year ago before publishing.  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).  Also, the
acronym ocl is already a prefix for the package's octave commands (in
order not to pollute the namespace in the octave symbol table).  Thus, I
have a strong interest in keeping "ocl" as the package name.

>> The rest is really up to you.  If you want to host a community package,
>> the review process might be a little stricter, but in your case it seems
>> realistic to go with that.
>>
> My vary personal suggestion is to keep it as external, because OF
> maintainers cannot keep up with all the work that is coming towards
> us, and you will suffer unnecessary delays.

As to the decision for community vs. external package:  I feel it makes
a crucial difference, but I myself do not have a strong opinion, due to
lack of knowledge.  The OCL package is mainly C++ code depending on
octave core sources, which would favor a community package status (in
the long run).  On the other hand, OCL has found intermediate attention
so far (being advertized only on this list, it has been downloaded ~130
times).  Collaboration for development is also somewhat simpler with an
external package.  Hence, I can currently see OCL as an "external
package", as an important advance in status.

What I have in mind is a transition time for migrating the ocl 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/

> I do not think that the ticket method is actually official, but I
> think is a good way to request a new repo.
> Please let me know and I will open the ticket (can do it yourself?) in
> the package release tracker [...].

Juan, can you please open the ticket with the following information:

   Name: ocl
   SCM:  mercurial
   Type: external package

> You can also follow Mike's example [...] and not even post it in OF, but
> announce the release in Admin and Help mailing list. This way you are
> the only responsible for delay in releases and you can always motivate
> people to join your team.

This is how it has been up to now - my project has been hosted on [1].
The drawback is that 'pkg install -forge ocl' obviously did not work for
the general user.  Being hosted at OF, it will.  And it will draw more
attention, as intended, also by several expressed opinions on this list.
 Bundling it into distros will be an additional advantage of the OF
package.

Thank you very much for your support!

Best,
Matt