Online Developer Meeting (2025-03-25): Difference between revisions
Jump to navigation
Jump to search
(→Today's topics: GSoC 2025) |
m (Add commentary) |
||
(11 intermediate revisions by 2 users not shown) | |||
Line 5: | Line 5: | ||
* Octave 10.1.0 release | * Octave 10.1.0 release | ||
** What's left? Ready to release? | ** What's left? Ready to release? ['''Ready to release'''] | ||
** What about packages (not core Octave)? Are they ready? | *** Apply patch to make HTML and Qt documentation pretty? Or wait until first bug fix release? ['''Yes, apply patch'''] | ||
*** I know that financial package does not work, and that update is very simple (replace <code>.+</code> with <code>+</code>). | ** What about packages (not core Octave)? Are they ready? ['''Release Octave. Package maintainers will need to catch up'''] | ||
* New name for <code>-forge</code> option to <code>pkg</code>? | *** I know that financial package does not work, and that update is very simple (replace <code>.+</code> with <code>+</code>).['''Rik will prepare patch and submit to Patch Tracker'''] | ||
* New name for <code>-forge</code> option to <code>pkg</code>? ['''Yes. Start a Discourse thread to suggest a new name. "-forge" argument will persist, possibly forever'''] | |||
** Existing name implies SourceForge, and there are many other package repositories in use. | ** Existing name implies SourceForge, and there are many other package repositories in use. | ||
** Any change would need to see the <code>-forge</code> option persist for a very long time. | ** Any change would need to see the <code>-forge</code> option persist for a very long time. | ||
* Run-time checks for adequate libraries | * Run-time checks for adequate libraries | ||
** BLAS library can be correct at compile-time, but switched at run-time to one that is not (MacOS and functions with <code>float</code> types). How should this be handled? | ** BLAS library can be correct at compile-time, but switched at run-time to one that is not (MacOS and functions with <code>float</code> types). How should this be handled? | ||
** Java 1.9 or higher is now required. How to check at run-time in <code>initialize_jvm</code> that JVM is adequate? | ** Java 1.9 or higher is now required for Octave 11. How to check at run-time in <code>initialize_jvm</code> that JVM is adequate? | ||
*** tactic #1: initialize JVM and call <code>FindClass("java/lang/ref/Cleaner")</code> and then tear down JVM if it is not adequate. | *** tactic #1: initialize JVM and call <code>FindClass("java/lang/ref/Cleaner")</code> and then tear down JVM if it is not adequate. | ||
*** tactic #2: check Java version number against 1.9 before initializing (but may be difficult to have cross-platform compatibility) | *** tactic #2: check Java version number against 1.9 before initializing (but may be difficult to have cross-platform compatibility) | ||
* Shared library versioning and <code>api-v60</code> tag | * Shared library versioning and <code>api-v60</code> tag | ||
** Is Octave's own internal api tag required anymore? | ** Is Octave's own internal api tag required anymore? ['''Apparently, yes. While shared library versioning will probably work on Linux, libraries on Windows do not have the same CURRENT:REVISION:AGE structure'''] | ||
** Does <code>liboctmex</code> need to check version anymore? Or is this already handled by <code>oct-shlib.cc</code> | ** Does <code>liboctmex</code> need to check version anymore? Or is this already handled by <code>oct-shlib.cc</code> <code>OCTAVE_API_VERSION</code> is only used to check version match when loading <code>.oct</code> files. This may only matter on systems that don't have proper library versioning. But even on those systems, we might be able to perform a check based on shared library versions stored in the <code>.oct</code> file instead of using <code>OCTAVE_API_VERSION</code>. | ||
* Sloppy Numfocus website? (https://numfocus.org/project/gnu-octave). Clicking on Octave logo goes to galaxyproject.org, not Octave web site. | * Sloppy Numfocus website? (https://numfocus.org/project/gnu-octave). Clicking on Octave logo goes to galaxyproject.org, not Octave web site. [1. Top logo should point to octave.org, 2. Contribute code logo should point to Get Involved page, 3. Bottom logo should point to website, not Mercurial archive] [jwe wrote e-mail, but website is still not updated as of 2025/03/23; reply received on 2025/03/19 promising an update "as quickly as possible". '''jwe will ping them again'''] | ||
* Discussion on continued use of Savannah Bug Tracker | * Discussion on continued use of Savannah Bug Tracker | ||
** Latest motivation to find something better is the inability to search for bug reports for old releases. | ** Latest motivation to find something better is the inability to search for bug reports for old releases. | ||
* GSoC 2025: Proposal Deadline on April 8 | * GSoC 2025: Proposal Deadline on April 8 ['''Conversation between Nick and Nir over whether to do GSOC this year'''] | ||
== Previous topics == | == Previous topics == |
Latest revision as of 19:21, 25 March 2025
- Date: Tuesday, March 25, 2025 @ 18:00 UTC Convert timezones here!
- Location: https://meet.jit.si/octave-dev
Today's topics
- Octave 10.1.0 release
- What's left? Ready to release? [Ready to release]
- Apply patch to make HTML and Qt documentation pretty? Or wait until first bug fix release? [Yes, apply patch]
- What about packages (not core Octave)? Are they ready? [Release Octave. Package maintainers will need to catch up]
- I know that financial package does not work, and that update is very simple (replace
.+
with+
).[Rik will prepare patch and submit to Patch Tracker]
- I know that financial package does not work, and that update is very simple (replace
- What's left? Ready to release? [Ready to release]
- New name for
-forge
option topkg
? [Yes. Start a Discourse thread to suggest a new name. "-forge" argument will persist, possibly forever]- Existing name implies SourceForge, and there are many other package repositories in use.
- Any change would need to see the
-forge
option persist for a very long time.
- Run-time checks for adequate libraries
- BLAS library can be correct at compile-time, but switched at run-time to one that is not (MacOS and functions with
float
types). How should this be handled? - Java 1.9 or higher is now required for Octave 11. How to check at run-time in
initialize_jvm
that JVM is adequate?- tactic #1: initialize JVM and call
FindClass("java/lang/ref/Cleaner")
and then tear down JVM if it is not adequate. - tactic #2: check Java version number against 1.9 before initializing (but may be difficult to have cross-platform compatibility)
- tactic #1: initialize JVM and call
- BLAS library can be correct at compile-time, but switched at run-time to one that is not (MacOS and functions with
- Shared library versioning and
api-v60
tag- Is Octave's own internal api tag required anymore? [Apparently, yes. While shared library versioning will probably work on Linux, libraries on Windows do not have the same CURRENT:REVISION:AGE structure]
- Does
liboctmex
need to check version anymore? Or is this already handled byoct-shlib.cc
OCTAVE_API_VERSION
is only used to check version match when loading.oct
files. This may only matter on systems that don't have proper library versioning. But even on those systems, we might be able to perform a check based on shared library versions stored in the.oct
file instead of usingOCTAVE_API_VERSION
.
- Sloppy Numfocus website? (https://numfocus.org/project/gnu-octave). Clicking on Octave logo goes to galaxyproject.org, not Octave web site. [1. Top logo should point to octave.org, 2. Contribute code logo should point to Get Involved page, 3. Bottom logo should point to website, not Mercurial archive] [jwe wrote e-mail, but website is still not updated as of 2025/03/23; reply received on 2025/03/19 promising an update "as quickly as possible". jwe will ping them again]
- Discussion on continued use of Savannah Bug Tracker
- Latest motivation to find something better is the inability to search for bug reports for old releases.
- GSoC 2025: Proposal Deadline on April 8 [Conversation between Nick and Nir over whether to do GSOC this year]
Previous topics
- Octave 9.4.0 has been released
- Release process of Octave 10
- Potential blockers
- BIST interaction with lastwarn (lastwarn) [Have package maintainers check and recode BIST tests where possible. Research eliminating "-quiet" option to warning() in Octave 11 and consider a new architecture for %!warning tests in Octave 11]
- ASAN/UBSAN bug reports [simple ones fixed. Remaining issues are long-term, large changes to go on dev branch]
- Ok to push fix for reading NA values on ARM [Change will be pushed and testing will occur with release candidate]
- Fix up minor
pkg
issue [1]? [Will make minor change in build system to export an empty global_list file] - Keep contributors that didn't explicitly agree to that in
doc/interpreter/contributors.in
? [Revert to existing behavior of 6 weeks ago. Octave will move to a new system for version 11] - Bug reporting style in
/etc/NEWS
(at start or end of one sentence summary) [Keep Arun's automated style, bug number in front] - Remaining Tasks
- C++ Style Check (Rik)
- Update
installer-files/README.html
in MXE Octave with version highlights.
- Potential blockers
- Sloppy Numfocus website? (https://numfocus.org/project/gnu-octave). Clicking on Octave logo goes to galaxyproject.org, not Octave web site. [1. Top logo should point to octave.org, 2. Contribute code logo should point to Get Involved page, 3. Bottom logo should point to website, not Mercurial archive]
- FYI: Colin created at GNU Octave group at https://codeberg.org/gnu-octave, as an alternative to GitLab.com and GitHub.com. If packager want to host their dev sites there, please reach out.
See also
- Next meeting: Online Developer Meeting (2025-04-22)
- Prev meeting: Online Developer Meeting (2025-02-25)