Online Developer Meeting (2024-06-25): Difference between revisions

From Octave
Jump to navigation Jump to search
(→‎Today's topics: Update notes from meeting)
 
Line 52: Line 52:
== See also ==
== See also ==


* Next meeting: [[Online Developer Meeting (2024-07-30)]]
* Next meeting: [[Online Developer Meeting (2024-07-23)]]
* Prev meeting: [[Online Developer Meeting (2024-05-28)]]
* Prev meeting: [[Online Developer Meeting (2024-05-28)]]


[[Category:2024]]
[[Category:2024]]
[[Category:Meetings]]
[[Category:Meetings]]

Latest revision as of 13:46, 22 July 2024

Today's topics[edit]

  • Progress update on GSoC projects
    • Colin and Andreas reported about the projects that they are mentoring: slow start on the project that Colin mentors; ahead of schedule for both projects that Andreas mentors.
  • OctConf 2024: no updates
  • Octave 9.2 release: successfully released last month
  • Traffic for Digital Ocean servers:
    • May 2024: 545 out of 4000 GB
    • June 2024 (until 25th): 340 out of 4000 GB
  • Moderation of mailing lists for bug tracker, patch tracker, and task tracker?
    • Ask users to answer on the Savannah interface if they answer by email. Or copy their answer to the reports on Savannah manually.
    • Currently jwe is the only moderator for the mailing lists for the notifications from savannah. Markus is willing to help with moderation.
    • We prefer to not have the notifications moderated by the GNU volunteer group.
    • For the help and maintainers mailing list, jwe, Jordi, and the GNU volunteer group are moderators currently.
  • Separate library for C mex interface?
    • No objections to create new library liboctmex (with potentially less frequent SOVERSION bumps to increase compatibility of .mex files between Octave version s).

Previous topics[edit]

  • We've used just 483GB of our 4000GB Digital Ocean outbound data transfer limit so far in May. We could consider (limited?) distribution of default branch builds for testing purposes.
  • Timing for next bugfix release: Expected by now, but delayed again because of bugs(?) - do we need another release candidate?
    • We do not need another RC. TODO: @jwe to do release.
    • Some discussion about release-candidates: we generally do RC only for 9.1 but not for 9.2, 9.3 etc.
  • Using Octave 10 (or 11?) to introduce the string class and other changes that will break backward compatibility without the usual two-release deprecation period.
    • Most seemed to feel that trying to maintain both via switches or
    • TODO: strings branch ASAP
    • TODO: @jwe to make posts/wiki whatever track/identify isuses
  • GSoC
    • Brief introduction to the three summer projects.
    • Note: focus on classdef.
  • Octave in MSYS2 (binary distributor for Windows MinGW)
    • Idea was to consider *adding* Octave to their project
      • this *might* decrease our maintainence efforts for Windows.
        • this is currently taking at least several hours per week.
      • but it is perhaps too fast-moving for us, as they do rolling releases
      • perhaps does not give us a .exe-based installer.
        • MXE is about cross-compiling from Linux to Windows
        • MSYS2 is about building **on** Windows
    • aside: don't bring back 32-bit binaries even if MSYS2 is about to drop support for that platform.
  • OctConf
    • Rik to continue thinking about San Fran for now.
  • Use of config.h / octave-config.h in Octave header files. What symbols belong in octave-config.h?
    • config.h should never be included in header files. The same holds for not-installed header files (like for libgui).
    • octave-config.h should preferably not define platform-specific macros. Only ever define macros for features that can be enabled or disabled by configure switches.
    • Design classes preferably such that the class definition doesn't differ depending on the target platform or Octave configuration. I.e., move conditional feature selection from the header files to the files that implement the member functions.
That means there should be no member functions or properties that are guarded by pre-processor macros in header files (independent on whether they are installed) if possible.


See also[edit]