[octave forge] releasing and template Makefiles

classic Classic list List threaded Threaded
28 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[octave forge] releasing and template Makefiles

JuanPi
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

Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]>:

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

Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> 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 <[hidden email]>:
> > 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

Reply | Threaded
Open this post in threaded view
|

Re: [octave forge] releasing and template Makefiles

Mike Miller-4
In reply to this post by JuanPi
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 (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [octave forge] releasing and template Makefiles

siko1056
On Thu, Mar 14, 2019 at 6:48 PM Mike Miller <[hidden email]> wrote:
On Thu, Mar 14, 2019 at 16:16:00 +0100, JuanPi wrote:
> So how we speed up and make easier the release process?

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


I think what JuanPi is referring to is the step 12:  Some Octave Forge admin has to accept the reviewed package put the released tarball to [1], and finally announce the package update on the website (updated list of functions and so on) to make `pkg install -forge` work.

Oliver did lots of work last year to make Octave Forge a great website and to formulate a SourceForge based release procedure.  I am too little involved in this project to judge the real effort, but I have the impression, that things are too complicated this year for the current manpower.  Is Oliver currently the only one who can do this final package release steps?  The SourceForge release list [2] counts 13 pending items over two months.  Did the Octave Forge release process stall?

Kai

Reply | Threaded
Open this post in threaded view
|

Re: [octave forge] releasing and template Makefiles

Mike Miller-4
On Thu, Mar 14, 2019 at 21:55:39 +0100, Kai Torben Ohlhus wrote:
> I think what JuanPi is referring to is the step 12:  Some Octave Forge
> admin has to accept the reviewed package put the released tarball to [1],
> and finally announce the package update on the website (updated list of
> functions and so on) to make `pkg install -forge` work.

I honestly don't think he is, he asked about how non-admins can help
with the review process. JuanPi can you clarify if that's what you are
asking about?

I think he is referring to helping to do the work of peer review of
pending packages, resulting in feedback to the package maintainer or
comments on the Forge tracker saying that the package looks good. The
purpose of this is to help reduce the workload of the admin who simply
needs to "push the button" to publish the package.

If we have more automated QA testing of packages and help with peer
review from other package developers, I think the work of the admin can
be vastly reduced to simply "ok, this package has met all of these
checkboxes, publish it".

Ultimately the Octave Forge "admin" could simply be a webhook that
validates that certain tests have been done on the package release
candidate and pushes a tag and publishes a tarball.

> Oliver did lots of work last year to make Octave Forge a great website and
> to formulate a SourceForge based release procedure.  I am too little
> involved in this project to judge the real effort, but I have the
> impression, that things are too complicated this year for the current
> manpower.  Is Oliver currently the only one who can do this final package
> release steps?  The SourceForge release list [2] counts 13 pending items
> over two months.  Did the Octave Forge release process stall?

Yes, Julien has mentioned a couple days ago that Oliver is currently the
only one signed up as an Octave Forge admin with the power to publish
packages.

My point is that the workload of the one or two Octave Forge admins
shouldn't have to extend to doing all of the quality control and package
validation steps I listed earlier. That quickly leads to overwork and
burnout.

I would be happy to volunteer as an Octave Forge release admin if other
people are willing to help with independent review of the package
validation steps.

--
mike

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [octave forge] releasing and template Makefiles

apjanke-floss
In reply to this post by siko1056


On 3/14/19 4:55 PM, Kai Torben Ohlhus wrote:

> I think what JuanPi is referring to is the step 12:  Some Octave Forge
> admin has to accept the reviewed package put the released tarball to
> [1], and finally announce the package update on the website (updated
> list of functions and so on) to make `pkg install -forge` work.
>
> Oliver did lots of work last year to make Octave Forge a great website
> and to formulate a SourceForge based release procedure.  I am too little
> involved in this project to judge the real effort, but I have the
> impression, that things are too complicated this year for the current
> manpower.  Is Oliver currently the only one who can do this final
> package release steps?  The SourceForge release list [2] counts 13
> pending items over two months.  Did the Octave Forge release process stall?
>
> Kai
>
> [1]
> https://sourceforge.net/projects/octave/files/Octave%20Forge%20Packages/Individual%20Package%20Releases/
> [2] https://sourceforge.net/p/octave/package-releases/

If more manpower can help here, I'd be willing to volunteer, too. As a
former Mac Homebrew maintainer, I have some experience with package
managers and distro maintenance.

Cheers,
Andrew

Reply | Threaded
Open this post in threaded view
|

Re: [octave forge] releasing and template Makefiles

jbect
In reply to this post by JuanPi
Le 14/03/2019 à 16:16, JuanPi a écrit :
> 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

In my opinion, asking each package maintainer to have a "maintainer
Makefile" at the root of its package was not a good idea in the first
place, for two reasons :

1) It makes it very difficult to upgrade the Makefiles of all packages
when the OF admin improve the "template" Makefiles (unless they are
identical to the template version, but then there is no reason to put
them in the package).

2) It forces package maintainers to learn about Makefiles (again, unless
they are satisfied with the template version, but then...).


Again in my opinion : Makefiles are an overly powerful tool for the
simple administrative tasks that we need to perform with packages (with
most packages, at least).

I prefer the approach of R which provides simple commands such R CMD
check, R CMD build, R CMD install, etc. [1].

Similarly in Rust : cargo build, cargo doc, cargo install, etc. [2].


Just my 2 cents...

@++
Julien


[1]
https://cran.r-project.org/doc/manuals/R-exts.html#Checking-and-building-packages

[2] https://doc.rust-lang.org/cargo/commands/index.html


Reply | Threaded
Open this post in threaded view
|

Re: [octave forge] releasing and template Makefiles

Juan Pablo Carbajal-2
> In my opinion, asking each package maintainer to have a "maintainer
> Makefile" at the root of its package was not a good idea in the first

This is very personal I agree, but what would be the alternative to
simplify/automate the building, checking install process?

> I prefer the approach of R which provides simple commands such R CMD
> check, R CMD build, R CMD install, etc. [1].
> Similarly in Rust : cargo build, cargo doc, cargo install, etc. [2].
What is the infrastructure needed to do this?

Please note the that one of the core problems of Octave Forge is
manpower, implementing more infrastructure is probably out of the
question.
One could reduce the need for control/curation (e.g. as many other
languages do), this was partly achieved by allowing pkg to install
form urls.
Or we can automatize as much as we can so all contributors can do it
if they wish to (including releasing, which now is totally
bottlenecked)

I will collect Mike's contributions, and see if I can split the
current monolithic template.

@Kai: yes, releases are currently stalled.

Reply | Threaded
Open this post in threaded view
|

Re: [octave forge] releasing and template Makefiles

nrjank
In reply to this post by Mike Miller-4


On Thu, Mar 14, 2019, 5:48 PM Mike Miller <[hidden email]> wrote:
On Thu, Mar 14, 2019 at 16:16:00 +0100, JuanPi wrote:
> So how we speed up and make easier the release process?

.

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

Can that process be templated on the octave wiki, so that a pkg maintainer can copy the template, label for the candidate release, announce it with a link to maintainers@, and then non admons could help with parts and note status back to the wiki?
-
Reply | Threaded
Open this post in threaded view
|

Re: [octave forge] releasing and template Makefiles

Colin Macdonald-2
On 2019-03-14 6:31 p.m., Colin Macdonald wrote:

> On 2019-03-14 5:49 p.m., Nicholas Jankowski wrote:
>> Can that process be templated on the octave wiki, so that a pkg
>> maintainer can copy the template, label for the candidate release,
>> announce it with a link to maintainers@, and then non admons could
>> help with parts and note status back to the wiki?
>
> Easier to just paste it into the release tracker bug as a comment?
>
> Put the text of checklists on the wiki and then reviewers can copy-paste
> it and fill in some check boxes...  [x], [n/a], [F], etc

Oops forgot to reply-to-list.

Anyway, I put my money where my mouth is started:

https://wiki.octave.org/Reviewing_Octave-Forge_packages

Please help flesh that out...

Colin

Reply | Threaded
Open this post in threaded view
|

Re: [octave forge] releasing and template Makefiles

Colin Macdonald-2
In reply to this post by nrjank
On 2019-03-14 5:49 p.m., Nicholas Jankowski wrote:
> Can that process be templated on the octave wiki, so that a pkg
> maintainer can copy the template, label for the candidate release,
> announce it with a link to maintainers@, and then non admons could help
> with parts and note status back to the wiki?
>

 > Easier to just paste it into the release tracker bug as a comment?
 >
 > Put the text of checklists on the wiki and then reviewers can
copy-paste it and fill in some check boxes...  [x], [n/a], [F], etc

Oops forgot to reply-to-list.  Anyway, I put my money where my mouth is
started:

https://wiki.octave.org/Reviewing_Octave-Forge_packages

Please help flesh that out...

Colin

Reply | Threaded
Open this post in threaded view
|

Re: [octave forge] releasing and template Makefiles

Olaf Till-2
In reply to this post by Mike Miller-4
On Thu, Mar 14, 2019 at 02:37:36PM -0700, Mike Miller wrote:
> I would be happy to volunteer as an Octave Forge release admin if other
> people are willing to help with independent review of the package
> validation steps.

It would be nice if you could help as such a release admin. (And you
already have the necessary access rights.)

I'm willing to help with reviewing and saying 'ok, you can release',
and maybe, if necessary, with some knowledge on the 'formalities'
(although my knowledge may be a bit outdated).

I'll try to do this testing for some packages in the queue this
weekend.

But my current time resources are not much better than at the time I
stepped back from administration, so further such 'testers and
ok-sayers' should be necessary. JohnD said he would help...?

To my experience, in the release procedure, much of the time is spent
in things that can't be automatized, e.g. in helping maintainers to
solve some problems. But with this, the people at the maintainers list
can be of great value.

Olaf

--
public key id EAFE0591, e.g. on x-hkp://pool.sks-keyservers.net

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [octave forge] releasing and template Makefiles

jbect
In reply to this post by Juan Pablo Carbajal-2
Le 14/03/2019 à 23:17, Juan Pablo Carbajal a écrit :
>> In my opinion, asking each package maintainer to have a "maintainer
>> Makefile" at the root of its package was not a good idea in the first
> This is very personal I agree, but what would be the alternative to
> simplify/automate the building, checking install process?

As in the examples cited below : a set of "developer tools", provided
for instance as a package.

>> I prefer the approach of R which provides simple commands such R CMD
>> check, R CMD build, R CMD install, etc. [1].
>> Similarly in Rust : cargo build, cargo doc, cargo install, etc. [2].



Reply | Threaded
Open this post in threaded view
|

RE: Re: [octave forge] releasing and template Makefiles

JohnD
In reply to this post by jbect
>
> Message: 3
> Date: Fri, 15 Mar 2019 20:19:44 +0100
> From: Olaf Till <[hidden email]>
> To: Mike Miller <[hidden email]>
> Cc: Kai Torben Ohlhus <[hidden email]>, JuanPi
> <[hidden email]>, [hidden email]
> Subject: Re: [octave forge] releasing and template Makefiles
> Message-ID: <20190315191944.lljeoydo2yd3xy7m@till>
> Content-Type: text/plain; charset="us-ascii"
>
> On Thu, Mar 14, 2019 at 02:37:36PM -0700, Mike Miller wrote:
> > I would be happy to volunteer as an Octave Forge release admin if other
> > people are willing to help with independent review of the package
> > validation steps.
>
> It would be nice if you could help as such a release admin. (And you
> already have the necessary access rights.)
>
> I'm willing to help with reviewing and saying 'ok, you can release',
> and maybe, if necessary, with some knowledge on the 'formalities'
> (although my knowledge may be a bit outdated).
>
> I'll try to do this testing for some packages in the queue this
> weekend.
>
> But my current time resources are not much better than at the time I
> stepped back from administration, so further such 'testers and
> ok-sayers' should be necessary. JohnD said he would help...?
>
> To my experience, in the release procedure, much of the time is spent
> in things that can't be automatized, e.g. in helping maintainers to
> solve some problems. But with this, the people at the maintainers list
> can be of great value.
>
> Olaf
>

I'm still volunteering

I did go through a few of the pending packages and checked whether they will
compile under mxe-octave and then natively in windows.


Reply | Threaded
Open this post in threaded view
|

Re: [octave forge] releasing and template Makefiles

apjanke-floss
In reply to this post by Colin Macdonald-2

On 3/14/19 10:19 PM, Colin Macdonald wrote:

> On 2019-03-14 5:49 p.m., Nicholas Jankowski wrote:
>> Can that process be templated on the octave wiki, so that a pkg
>> maintainer can copy the template, label for the candidate release,
>> announce it with a link to maintainers@, and then non admons could
>> help with parts and note status back to the wiki?
>>
>
>  > Easier to just paste it into the release tracker bug as a comment?
>  >
>  > Put the text of checklists on the wiki and then reviewers can
> copy-paste it and fill in some check boxes...  [x], [n/a], [F], etc
>
> Oops forgot to reply-to-list.  Anyway, I put my money where my mouth is
> started:
>
> https://wiki.octave.org/Reviewing_Octave-Forge_packages
>
> Please help flesh that out...
>
> Colin
>

Here's something that might be useful:

I've written a function to install and test all Octave Forge packages,
testify.install_and_test_forge_pkgs, in my experimental Testify package.
https://github.com/apjanke/octave-testify. This could be used in testing
packages, or to validate the development Octave code against existing
Forge packages.

To use it:

pkg install -forge doctest
pkg install
https://github.com/apjanke/octave-testify/releases/download/v0.2.0/testify-0.2.0.tar.gz
pkg load testify
testify.install_and_test_forge_pkgs

Mike, it includes doctest support, but it's disabled by default due to
some errors it's throwing. I'll submit a bug/patch to doctest shortly.

Here's results for the 3 major OSes:

macOS:
https://github.com/apjanke/octave-testify/files/2975787/octave-testify-ForgePkgTester-2019-03-17_17-53-30.zip
Linux:
https://github.com/apjanke/octave-testify/files/2975883/octave-testify-ForgePkgTester-2019-03-17_16-07-51.zip
Windows:
https://github.com/apjanke/octave-testify/files/2975938/octave-testify-ForgePkgTester-2019-03-17_19-27-37.zip

The results include the test log itself, summary results, and captured
build logs for package installations which had configure/make components.

Here's what the state of the world looks like on Linux (an Ubuntu Xenial
box with basic libs installed):

========  PACKAGE INSTALL AND TEST RESULTS  ========

Tested 67 packages in 47:32
Packages tested (67): instrument-control arduino fpl splines msh bim
bsltl cgi control signal communications io statistics struct optim
data-smoothing database dataframe dicom divand doctest econometrics
fem-fenics financial fits ga general generate_html geometry gsl image
image-acquisition interval level-set linear-algebra lssa ltfat mapping
miscellaneous mpi mvn nan netcdf ncarray nurbs octclip octproj optics
optiminterp parallel quaternion queueing secs1d secs2d secs3d sockets
sparsersb stk strings symbolic tisean tsa vibes video vrml windows zeromq

Packages passed (32):
   instrument-control fpl bim bsltl cgi io statistics dataframe divand
doctest financial general generate_html geometry lssa ltfat mapping mvn
nurbs octclip optics optiminterp quaternion queueing secs1d secs3d
sockets stk symbolic vibes windows zeromq

Skipped tests on known-bad packages (2):
   control
   level-set

Failed package installations (28):
   signal
   communications
   struct
   optim
   data-smoothing
   database
   dicom
   econometrics
   fem-fenics
   fits
   gsl
   image-acquisition
   interval
   linear-algebra
   miscellaneous
   mpi
   nan
   netcdf
   ncarray
   octproj
   parallel
   secs2d
   sparsersb
   strings
   tisean
   tsa
   video
   vrml

Failed package tests (5):
   arduino
   splines
   msh
   ga
   image


Cheers,
Andrew

Reply | Threaded
Open this post in threaded view
|

Re: [octave forge] releasing (was: ... and template Makefiles)

Olaf Till-2
In reply to this post by Olaf Till-2
On Fri, Mar 15, 2019 at 08:19:44PM +0100, Olaf Till wrote:
> On Thu, Mar 14, 2019 at 02:37:36PM -0700, Mike Miller wrote:
> > I would be happy to volunteer as an Octave Forge release admin if other
> > people are willing to help with independent review of the package
> > validation steps.

Collectively reviewed and probably ready for release now:

- signal
- zeromq
- dicom
- struct
- optim
- instrument-control
- database ?
- (probably soon statistics)

Hint for future reviews: check licenses ('licensecheck -r' plus some
manual checks). Change wiki correspondingly?

Olaf

--
public key id EAFE0591, e.g. on x-hkp://pool.sks-keyservers.net

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [octave forge] releasing (was: ... and template Makefiles)

Olaf Till-2
On Sat, Mar 23, 2019 at 08:27:07PM +0100, Olaf Till wrote:
> Hint for future reviews: check licenses ('licensecheck -r' plus some
> manual checks). Change wiki correspondingly?

Other issues to check:

'pkg' doesn't seem to care for file permissions even in system wide
installations. So it should be checked that the package files are
readable/executable by all users. A current maintainer Makefile
automatically sets the correct permissions in tarball creation so that
later checking isn't necessary.

Contains no hidden files, results of configure runs, etc.. Again, this
should be cared for by the maintainer Makefile so that later checking
isn't necessary.

Version number in src/configure.ac, if this file is present.

Olaf

--
public key id EAFE0591, e.g. on x-hkp://pool.sks-keyservers.net

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [octave forge] please give me access again

Olaf Till-2
Mike or Carnë,

could one of you give me write access to OF again? I'd like to help
again in putting (now collectively reviewed) releases online (still
help of others in this highly welcome). Also, I'd like to make some
minor fixes to the new web pages.

Olaf

--
public key id EAFE0591, e.g. on x-hkp://pool.sks-keyservers.net

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [octave forge] releasing

apjanke-floss
In reply to this post by Olaf Till-2

On 3/24/19 3:14 AM, Olaf Till wrote:

> On Sat, Mar 23, 2019 at 08:27:07PM +0100, Olaf Till wrote:
>> Hint for future reviews: check licenses ('licensecheck -r' plus some
>> manual checks). Change wiki correspondingly?
>
> Other issues to check:
>
> 'pkg' doesn't seem to care for file permissions even in system wide
> installations. So it should be checked that the package files are
> readable/executable by all users. A current maintainer Makefile
> automatically sets the correct permissions in tarball creation so that
> later checking isn't necessary.
>
> Contains no hidden files, results of configure runs, etc.. Again, this
> should be cared for by the maintainer Makefile so that later checking
> isn't necessary.
>
> Version number in src/configure.ac, if this file is present.
>
> Olaf
>

I've added a "pkj review" command to Packajoozle to do automatable parts
of package distribution review.

https://github.com/apjanke/octave-packajoozle/issues/31
https://github.com/apjanke/octave-packajoozle/blob/bb9d1af90f2414a25eef821007be3d23f176819a/inst/%2Bpackajoozle/%2Binternal/PkgReviewer.m#L131-L268

You can point it at a package distribution tarball file, a local clone
of the package repo, or a published Forge package by name@version.

pkj review image-2.10.0.tar.gz
pkj review /path/to/my/local/clone/of/octave-image
pkj review image@2.10.0

It'll report any bad findings.

It includes a check for all package files being world readable, that the
version number in src/configure.ac is present and matches that in
DESCRIPTION, and that there are no file droppings from configure or
make. It also checks that installing, loading, unloading, and
uninstalling the package all work cleanly (that is, they succeed and
there were no warnings raised).

(To come: running the BIST and doctest unit tests on the package.)

(Olaf, how would you determine which files in the distribution should be
executable?)

Give it a try if you're interested, and let me know if there are any
additional checks you'd like done.

Examples:

 >> pkj review -verbose io-2.4.12.tar.gz
PkgReviewer: Working dir:
/var/folders/_4/9mx5ryp52bb_z6drbcbrhwl40000gn/T/packajoozle/pkj-review/work-sB33Cr
PkgReviewer: Reviewing io 2.4.12 from file io-2.4.12.tar.gz
PkgReviewer: Examining distribution file contents
PkgReviewer: Installing package
Installed io 2.4.12 from
/var/folders/_4/9mx5ryp52bb_z6drbcbrhwl40000gn/T/packajoozle/pkj-review/work-sB33Cr/io-2.4.12.tar.gz
to user pkg dir
For information about changes from previous versions of the io package,
run 'news io'.
PkgReviewer: Loading package
pkj: loading: io 2.4.12
PkgReviewer: Unloading package
PkgReviewer: Uninstalling package
PkgReviewer: All checks finished
Package review failed for io-2.4.12.tar.gz.
Errors:
     Version in configure.ac AC_INIT(...) does not match version in
DESCRIPTION

 >> pkj review -verbose statistics-1.4.0.tar.gz
PkgReviewer: Working dir:
/var/folders/_4/9mx5ryp52bb_z6drbcbrhwl40000gn/T/packajoozle/pkj-review/work-C7FBeP
PkgReviewer: Reviewing statistics 1.4.0 from file statistics-1.4.0.tar.gz
PkgReviewer: Examining distribution file contents
PkgReviewer: Installing package
warning: doc_cache_create: unusable help text found in file 'gmdistribution'
Installed statistics 1.4.0 from
/var/folders/_4/9mx5ryp52bb_z6drbcbrhwl40000gn/T/packajoozle/pkj-review/work-C7FBeP/statistics-1.4.0.tar.gz
to user pkg dir
For information about changes from previous versions of the statistics
package, run 'news statistics'.
PkgReviewer: Loading package
pkj: loading: io 2.4.12, statistics 1.4.0
PkgReviewer: Unloading package
PkgReviewer: Uninstalling package
PkgReviewer: All checks finished
Package review failed for statistics-1.4.0.tar.gz.
Errors:
     Warnings during package installation: doc_cache_create: unusable
help text found in file 'gmdistribution'

Cheers,
Andrew

12