Re: OCL package 1.0.0 released

[Matthias W. Klein]

Dear Olaf,

thanks for your advice.

>> Next question is whether we also replicate the existing releases, 4 so
>> far
>
> I'd say no. They most likely would require changes, and with changes
> it would be different releases.
>
>> and I am currently preparing a new one.
>
> Let's concentrate on the upcoming one, I'd say.
>

Ok.

>> 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.
>
> Ok from my side. And to be honest: most of the work is likely to be on
> your shoulders anyway, even with community status.
>
>> 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).
>
> Any release is reviewed, how much 'peer' depends on the situation. A
> new package will be reviewed more thoroughly. The usual way is that
> the maintainer (you) makes something ready of which he thinks it can
> be released. With reviewing, changes may be applied. If you have
> specific questions before, you can ask them at the maintainers list.
>

What I made out of all this is twofold:

1.) For my "legacy" sourceforge project page, I developed a last
not-to-replicate release (1.1.0), published today. I wanted to have this
out by the end of the year which probably (at least from my side) would
not have worked with reviewing.

2.) For OF, and intended to be ready during the first days of the new
year, I am preparing a release tarball (1.1.1), containing small
editorial and content changes from my side, and intended for thorough
review as a community package, and which I will upload to the OF release
tracker, together with the HTML doc tarball.

For the OF release tracker, I will include the revision ID and md5sum
and how I tested it already. Anything else needed right away?

My aim for the OF release would be to get it into the next official
octave bundles (5.2 or 6.1, as being announced). I hope this will turn
out to be achievable together, let's see.

>> 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).
>
> We can sort this out time by time. In the download from your origingal
> repository, the directory structure wasn't flat, there were inst/ and
> src/ directories. These should be re-introduced now (i.e., be conform
> with the docs of Octaves pkg() for new packages). You can leave your
> Makefile under src/. Additionally, there should be a Makefile at root,
> with targets 'dist' and related ones.
>

Yes, we can get to this step by step.

What I meant was a (maybe uncommon) differentiation of repository
directory structure from tarball directory structure. The former (the
repository) has been flat in my case, for debugging / developing; the
latter (the release tarball) contains subdirectories, as required by
'pkg', the subdirectories being created by my 'make dist' in my case.
But, as we said, we can get to this in detail later.


Best,
Matt