Re: [octave forge] releasing and template Makefiles

[Mike Miller]

On Thu, Mar 14, 2019 at 16:16:00 +0100, JuanPi wrote:
> So how we speed up and make easier the release process?

Honestly, automation, which of course someone would need to volunteer to
help create. The checks that I know of can all be automated (errors,
warnings, test failures, validate the DESCRIPTION and INDEX files). The
human checks could be limited to reading the NEWS and reading the
generated HTML documentation.

> 1. Olaf mentioned that non-admin can help in the review process. How?
> I would be willing to do it, but I have no clue where are the
> tools/procedures to review releases.

I don't know if it's documented anywhere, but I would review by

1. Pick a package at https://sourceforge.net/p/octave/package-releases/
2. Install the release candidate in latest Octave release
3. Look for compiler errors and warnings
4. Run all tests using runtests (including tests in the src dir)
5. Run doctest on all functions (optional)
6. Repeat steps 2-5 in other versions of Octave as available
7. Run generate_package_html
8. Look for makeinfo errors and warnings during HTML build
9. Unpack and spot-check the generated HTML documentation
10. Read NEWS and see if it makes sense, version and date match
11. See if all functions are listed in INDEX

It would be good to document common problems that reviewers can check
for, things like

* INDEX is missing some new functions added
* NEWS has not been updated or is missing something big
* Version numbers or dates do not match between DESCRIPTION and NEWS
* Common makeinfo errors like "@bye seen before @end deftypefn"
* DESCRIPTION says pkg works with old Octave 4.x but it fails for me
* Obviously, compiler errors, warnings, test failures

> 2. Our developer tools are good but still too mangled. I tried to help
> with the Makefiles, but got demotivated by the constant effort to make
> a complicated Makefiel that covers all possible cases. My suggestion
> is that we split Makefile sin use cases and offer all the templates,
> instread of just one for all. the cases Is se are: Makefile_<cvs>_<pkg
> content>.
> Where <cvs> is one of {mercurial, git} and <pkg_content> is one of
> {mfileonly, C-C++-FORTRAN, nonOFdependencies}.
> The last two would be also distributed with an example bootstrap and
> configure script, this is for example for packages like odepkg
> (SUNDIALS) or packages that depedn oin python modules.
> We can start with the simple Makefile_git Makefile_mercurial to reduce
> the complexity of the current offered Makefile template.

I'd say just do it, this doesn't seem like a big deal. The signal
package top-level Makefile is very different from the template Makefile
recommended on the Octave Forge site and I'm quite happy with it. Feel
free to adapt it to your package if you want.

IMHO the important part of the top-level Makefile is the interface, does
it support some enumerated set of targets that everyone can agree on.

> Another issue is that the user's .octaverc is not loaded, supposedly
> to increase reproducibility. I understand this in the case of
> compiling or preparing the documentation. however I do not see the
> point of doing this also for the "install" or the "run" rule. Both
> things should use the user configs to test possible environments (e.g.
> I could have several rc files and install and run with those). I do
> not see how install and run have to be reproducible, the packages are
> isntalled and run in different environments.

Again, just do it. The signal package Makefile does not use --norc.

-- 
mike

signature.asc
Description: PGP signature