Re: OCL package 1.0.0 released

[Matthias W. Klein]

Dear Olaf,

>> 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?
> Yes, it should.

Done. The OF repo content is a current clone of the SF repo.

Next question is whether we also replicate the existing releases, 4 so
far, and I am currently preparing a new one.

>>> 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.
> As you can read at our 'Developers' page, not the issues you mention,
> but others, are supposed to be a base for deciding between 'community'
> and 'external'.
>
> If you want to decide together with others what is the best way to
> develop the package, and you are willing to sometimes follow a
> decision although you think another would be better, choose
> 'community'. If you want to decide everything yourself, choose
> 'external'. But in the latter case, not all of us may be motivated to
> help. Note also that an external package may cause a problem if it
> provides a very desirable functionality and its owner stops
> maintainance or develops the package into a direction not thought
> ideal by the Octave community.

With 'controversial' I meant that the question has been discussed
controversially on the maintainer ML, regarding ocl.

I recently expressed that, given the tight dependency of ocl to octave
sources, I would favor a community package status at least in the long
run. It is perfectly acceptable for me to start this long run early.

Here is my suggestion: I am preparing the next release, still as a
one-man show, and we subsequently turn ocl into a community package.
Does this sound like a plan? It will be good to agree on such a course
of action in advance.

The suggestion would mean I can expect to release version 1.1.0 soon. We
should agree on whether we want peer review before/with release or not
(yet). For the following collaboration to start I see a bunch of
possible aspects how peers can contribute to raise the project to a more
elaborate level (you mentioned a few), but I am very open for further
suggestions.

>>> - 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 don't understand why this hinders you to add a root level Makefile
> for the release-related stuff. src/Makefile should still be there, of
> course, and you are free to use it as you like. A decent additional
> root level Makefile makes things easier for the person who has to
> check and publish the release. Indeed, it is a 'hard' requirement for
> all OF packages.

I was unclear, sorry for the misunderstanding. The ocl repo currently
has a flat directory "structure" and one Makefile (at this "root level")
which does everything I needed so far: without arguments, it compiles
the sources locally; with other targets it aids in development; and
'make dist' yields the release tarball (which contains a non-trivial
internal directory structure as needed, including a clone of the single
Makefile at src/Makefile).

I'll be happy to discuss changes, hopefully maintaining the local
incremental building feature which I use most of the times during
developments and which the OF template, to best of my knowledge, does
not offer so far.

Best,
Matt