Editing OctConf 2018 Notes

Jump to navigation Jump to search
Warning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to your username, along with other benefits.

The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then publish the changes below to finish undoing the edit.

Latest revision Your text
Line 42: Line 42:


; test coverage
; test coverage
: We can already get the line coverage of our test suite if we run make coverage but that only includes the C++ code.  jwe says that it would be simple to add some fields to the interpreter that would allow us to also get the line coverage.  This would only be done if Octave was built with specific flags.  Oliver pointed out that because of vectorized options, line coverage in m file is not as useful as in other languages since the conditions that in other languages is done with if blocks, are instead done by using indexing with an empty array of an array of false elements.
; measurements of performance
; measurements of performance
: the test suite is not the best measure of performance.  We are estimating that most of its time is spent on running assert which is irrelevant for real Octave programs.  It is  also mainly cover corner cases and a lot of tests are if it fails when input checking is correct.  We should instead have real Octave programs that we used for benchmarking.  There wasn't much discussion of this topic beyond noting the problem exists.


; Octave Forge community
; Octave Forge community
:Currently, there is a high barrier to publish new packages for Octave on Octave-Forge. This mainly comes from the maintenance burden that the Octave Forge Community has with the packages. In particular:
Currently, there is a high barrier to publish new packages for Octave on Octave-Forge. This mainly comes from the maintenance burden that the Octave Forge Community has with the packages. In particular:
:* The package has to be actively maintained in order to stay compatible with updates to Octave core
* The package has to be actively maintained in order to stay compatible with updates to Octave core
:* There is no known good solution to have a Matlab-compatible package, which respects the requirements of an OF package
* There is no known good solution to have a Matlab-compatible package, which respects the requirements of an OF package
:* The list of initial requirements (legal and technical) is quite high for outside contributers, especially for domain experts (which we want to address) who are no software engineers
* The list of initial requirements (legal and technical) is quite high for outside contributers, especially for domain experts (which we want to address) who are no software engineers
: This creates problems for some external package authors, who basically want to release on their own. Also, this is not resolved by the *two package groups* that we have introduced during the last year.
This creates problems for some external package authors, who basically want to release on their own. Also, this is not resolved by the *two package groups* that we have introduced during the last year.
:
 
: We see potential for more Octave package publications, which come from “one-off” publications (e. g. with a book / thesis), existing Matlab packages (which also offer a Octave variant), and simple (experimental) libraries of m-files. To increase the pool of high-level users we need to reduce even more the burden to install and distribute packages independently.
We see potential for more Octave package publications, which come from “one-off” publications (e. g. with a book / thesis), existing Matlab packages (which also offer a Octave variant), and simple (experimental) libraries of m-files. To increase the pool of high-level users we need to reduce even more the burden to install and distribute packages independently.
:
 
: The problem that we see today is that Octave-Forge is two-fold: (1) a (collaborative) software development platform and (2) a (re-)distributor of software. So, these new use-cases would not be part of Octave-Forge. In the context of an increasing number of independent “Github developers” this is not needed so much.
The problem that we see today is that Octave-Forge is two-fold: (1) a (collaborative) software development platform and (2) a (re-)distributor of software. So, these new use-cases would not be part of Octave-Forge. In the context of an increasing number of independent “Github developers” this is not needed so much.
:
 
: To do this we bring back the idea of allowing `pkg` to download and install directly from a url to a `.zip` file or `.tar.gz` file, e.g. `pkg install 'https://myrepo.org/mypackage.zip'`
To do this we bring back the idea of allowing `pkg` to download and install directly from a url to a `.zip` file or `.tar.gz` file, e.g. `pkg install 'https://myrepo.org/mypackage.zip'`
:* There will be no checks (nor quality standard) on these packages and the user should be clearly warned:
* There will be no checks (nor quality standard) on these packages and the user should be clearly warned:
:** Security issue: With no https the download can be redirected. The user can be tricked into entering this command, which downloads and installs (=runs) arbitrary software.
** Security issue: With no https the download can be redirected. The user can be tricked into entering this command, which downloads and installs (=runs) arbitrary software.
:** Feedback/QA issue: If that package doesn't work, users are probably asking for help.
** Feedback/QA issue: If that package doesn't work, users are probably asking for help.
:* Should `pkg update` also work for these packages?
* Should `pkg update` also work for these packages?
:** Maybe no. Just re-run the install command.
** Maybe no. Just re-run the install command.
:** If needed, there could be an update url in the DESCRIPTION file
** If needed, there could be an update url in the DESCRIPTION file
:* We need to provide guidelines, recommendations and tools for people trying to distribute their packages. We are doing something in this direction, but we need a little boost here: https://octave.sourceforge.io/templates/Makefile, https://sourceforge.net/p/octave/example-package/ci/default/tree/
* We need to provide guidelines, recommendations and tools for people trying to distribute their packages. We are doing something in this direction, but we need a little boost here: https://octave.sourceforge.io/templates/Makefile, https://sourceforge.net/p/octave/example-package/ci/default/tree/
:* If a package can be installed directly from the repository, it would be supported out-of-the-box by Github, Gitlab, …
* If a package can be installed directly from the repository, it would be supported out-of-the-box by Github, Gitlab, …
:
 
:Also, we discussed a “package database” like it is done in Julia (see [https://github.com/JuliaLang/METADATA.jl] for a very lightweight solution, which only contains package names, URLs and version), but don't see advantages from that right now.
Also, we discussed a “package database” like it is done in Julia (see [https://github.com/JuliaLang/METADATA.jl] for a very lightweight solution, which only contains package names, URLs and version), but don't see advantages from that right now.


; packages into Octave core
; packages into Octave core
: Decided that Octave releases will include some core packages.  These will be developed along Octave core, in the same repository, and will be released at the same time.  For all purposes they will be a single software project.  However, they will still need to be loaded like any other packages.
: Initially, these packages will cover signal processing, statistics, image processing, optimisation, communications, and control.  Their aim is to be compatible with their Matlab counterparts and they will be partly imported from the existing Octave Forge packages.
: We won't import all packages in one go.  We will start with statistics because we have recently moved a bunch of core functions into it and so they will be easier to import back.  signal will probably follow but Pantxo pointed out that this would require a lot of work on its documentation.  optim and communications will probably go last since communications is abandoned and optim does not actually have many Matlab compatible functions.
: The current forge packages include extra functions that are not in the Matlab counterparts and their inclusion in the core packages will be decided on a case by case basis. Not sure what will happen with them most likely they would go into a separate package like statistics-legacy.


=== Doing ===
=== Doing ===


; merging of previous GSoC projects
; merging of previous GSoC projects
: Rik merged Ginesi's special functions and Carlo's worked remotely on merging Cristiano Dorigo's improvement of iterative solvers.
: Rik merged Ginesi's special functions and Carlo's worked on merging ode45
 
; polygon reconstruction algorithm
; polygon reconstruction algorithm
: Rik and Pantxo worked on this
: Rik and Pantxo worked on this
; new release
; new release
: jwe been preparing for wednesday's release
: jwe been preparing for wednesday's release
; dinner in town
; dinner in town
: That was a very nice time with much discussion about future of Octave and Octave Forge, packages, and makefiles.
; email maintainers mailing list with conclusions
; email maintainers mailing list with conclusions
: done


== Wednesday ==
== Wednesday ==


=== Talking ===
=== Talking ===
; SWAN presentation
: CERN presented their customized Jupyter instance named SWAN which integrates with the other CERN tools for data and data processing.
; make {{Codeline|--no-gui}} default
: Mike http://lists.gnu.org/archive/html/octave-maintainers/2018-03/msg00044.html suggested on the mailing to make this change for the upcoming 4.4 release.  We discussed it all together, and everyone agrees.  This should make things simpler for everyone.  There will be only one flag which will be {{Codeline|--gui}} to start the gui and will be used by launchers.  This will simplify the octave code too since we will no longer have to guess whether to start it or not based on whether we have persist or scripts to eval.
:
: We then coded that change.


; review our review of code contributions
; review our review of code contributions
: a quick rehash of previous discussions.  We do a lousy job at review contributions and would need better tools to make the reviewing easier.  However, no is available to have such a tool which actually means replacing savannah with our own instance.
; build system issues
 
; the complicated code in pkg
: Juan showed that the code in pkg is a bit overcomplicated.  Some changes were done to simplify it some 3-4 years ago but never got merged. Those changes no longer apply.  Juan will try to make those changes again but first will be adding tests for pkg.
 
; warning users if installing packages with url
: discussed adding a warning that a package was not community maintained if user tried to use a url, and required user to answer yes or no.  Decided against such warning.  We may instead consider add a warning in the future if user tries to install something with an insecure connection (http:// instead of https:// or file://)


=== Doing ===
=== Doing ===


; new Octave 4.2.2 release
; new Octave 4.2.2 release
: It was done.  In the process of merging default to stable, we may do that tomorrow instead.
; new release of image package
; new release of image package
: carandraug not even had time to get to it, too busy with changes to core and more discussions.
; more tests to increase code coverage
; more tests to increase code coverage
; CERN visit
; CERN visit
; email maintainers mailing list with conclusions


; email maintainers mailing list with conclusions


== Thursday ==
== Thursday ==
Line 133: Line 101:


; OctConf 2019
; OctConf 2019
: We discussed the place, date, fee, and objective of OctConf 2019.
; pending discussions and work
:  ----
: For '''place''', CERN offered to host it again next year.  However, it was also suggested that we should try other places to meet new people and make it easier for people from far away, namely west coast  USA.  However, this also means more work since it's new logistics and other places have different costs.  Seems like most contributions are European and flying them all to USA would be more expensive than flying the American developers to Europe.  CERN is also quite cheap.  Flying to Geneva from Europe is cheap, the rooms are free, and the CERN hotels are very affordable. It was also suggested to change place every two years or to come to CERN every two years with a new place each other year.  We decided to have a call for an organizer, with a deadline of 1st of May.  If no suitable option appears, then the place will be CERN. Rik will send out the call for organizer.
:  ----
: The '''date''' for the conference in 2019 must happen during the second half of March or the first half of April, according to the organizers availability.  If it happens at CERN, it must be after 17th of March to avoid the motor exposition.  As for the duration, next time it will be 3 full days instead of 2 days and two half days.  The morning of the first day will be planning for the other days and the last evening to discuss OctConf 2020.
: ----
: Because of free '''registration''', many registered people do not show.  This makes organization difficult, we don't know how much coffee to order, how many people for the restaurants, or the size of the room.  We will introduce a registration fee of ~ 20€ which then can be used to cover some costs of the social event.  Other possibilities is a much higher fee which would include the accommodation since if attendees are coming, they would have to pay anyway.  However, it was decided against since they will only see the high cost and decide against coming.
: ----
: This years conference was pretty much a '''developers''' conference.  There was a total of 3 talks with all other time spent on discussing developer topics and coding.  It was discussed the issue of Octave visibility and that a user space could exist during OctConf, which would be one day for users to present their work to each other and have some workshops.  This could even happen at the same time as developers would meet on other rooms.  It was decided against, as there was not enough interest among the developers.  This makes organization simpler since we also only need a smaller room with a whiteboard.  There will be john's yearly talk about the state of Octave and Rik will make a more outreach talk, more sales pitch, showing what can be done with Octave and where it is being used.


=== Doing ===
=== Doing ===


; email maintainers mailing list with conclusions
; email maintainers mailing list with conclusions
: done by carandraug
[[Category:OctConf]]
[[Category:2018]]
Please note that all contributions to Octave may be edited, altered, or removed by other contributors. If you do not want your writing to be edited mercilessly, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see Octave:Copyrights for details). Do not submit copyrighted work without permission!

To edit this page, please answer the question that appears below (more info):

Cancel Editing help (opens in new window)

Template used on this page: