Re: [octave forge] releasing and template Makefiles

[Ricardo]

Hello, Juan.
To help in the review process access
http://savannah.gnu.org/patch/?group=octave . There you can see the
patches submitted and comment.

To compile octave itself see
https://wiki.octave.org/Octave_for_Debian_systems#Compiling_from_source
. The packages are very different, they use different libraries, it
would be difficult to make everything follow the same pattern. Inside
octave >> pkg install -forge <package_name> you can semiautomatic
download and install what you need. You can change the code and
compile again after install. I don't remember if there is a commando
to download all packages sources. Are you trying to make a new octave
installation file and need all packages? I think I don't understand
your second point.

I don't find a bug report about the .octaverc not being loaded. Could
you give us more details?

Reproducible builds, implies only in compiling in the same
architecture produces the same binary always. The results are "close
reproducibility", I mean, they get the same results with an error
margin. See the assert function
https://octave.sourceforge.io/octave/function/assert.html , the
version  "assert (observed, expected, tol)"  have a tolerance
parameter.

Bye,
Ricardo.

2019-03-14 12:16 GMT-03:00, JuanPi <address@hidden>:
> Hi all,
>
> It seems ot me that the latest update tested our pipeline for releases
> in Octave Forge.
> As expected an institution built on people's voluntary time
> contribution, cannot have great control schemes, and this is showing
> in Octave Forge.
>
> So how we speed up and make easier the release process?
>
> 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.
>
> 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.
>
> 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.
>
> Regards,
>
>
> --
> JuanPi Carbajal
> https://goo.gl/ayiJzi
>
> -----
> “An article about computational result is advertising, not
> scholarship. The actual scholarship is the full software environment,
> code and data, that produced  the  result.”
> - Buckheit and Donoho
>
>