Re: [octave forge] releasing and template Makefiles

[JuanPi]

Hi Ricardo,

The post was related to Octave Forge packages, not Octave it self.
Thanks anyways!

On Thu, Mar 14, 2019 at 5:23 PM Ricardo <address@hidden> wrote:
>
> 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
> >
> >



-- 
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