Meeting 2024 01

Gluon Meetup 2024-01

13.02.2024 - 20:00 CET - mumble.freifunk.net

Notes from Last Meetup: Meeting-2023-06

Attendees

• [ 👤 djfe]
• [ 👤 blocktrron]
• [ 👤 grische]
• [ 👤 neocturne]
• [ 👤 rotanid]
• [ 👤 tom]
• [ 👤 goligo]
• [ 👤 maurele]

Topics

Please always note your name next to your topic

• [ 👤 tom], [ 👤 neocturne] new version scheme?
  • Problems with the current version scheme:
    • The year may change during the release process
    • Gluon release numbers look similar to OpenWrt release numbers, but don't line up
    • People in chat sometimes abbreviated version numbers in confusing ways ("Gluon 23")
    • While the whole of the first two numbers of our current version ("2023.2") refer to the major version, some versions look closer to each other than others (2023.1 vs 2023.2 looks closer than 2022.1 vs 2023.1)
  • Proposal by [ 👤 neocturne]: Switch to a simple MAJOR.MINOR scheme
    • Open question: Where do the new major versions start?
      • "Gluon 24" (avoid confusion with current release numbers)
      • "Gluon 18" (we've had a total of 17 major releases so far)
      • Please collect other ideas until next meeting
  • Another idea that was brought up: base our version numbers on the underlying OpenWrt version
    • ([ 👤 neocturne]) Doesn't seem better than our current scheme
  • Avantages of the old scheme:
    • The approximate age of a release can easily be derived from the version number
  • Any change of the version scheme will break numeric ordering of tags
  • We have not made a decision on this point yet. Alternative proposals can be collected until the next meetup.
• [ 👤 neocturne] Doc versions
  • Currently docs for each tagged version are available on RTD. The list is getting very long, and it is generally a bad idea to link to specific tagged versions, as we can't update them with corrections.
  • I propose to switch to have only one doc version for each stable branch + master. Existing links to tagged versions can be kept working by setting up redirects on RTD.
  • As an alternative, the tagged versions could be hidden, but still be built. This solves the issue of having a long list, but not that the tagged versions can't be updated if links to them exist.
  • Conclusion: Check if the "latest" build (current stable branch) can be set as the latest version linked in the "obsolete version" headers on RTD. We'd like to avoid adding lots of redirects; making tags as hidden should be sufficient.
• [ 👤 tomh] update Maintainers?
  • there is a number of inactive Committers, maybe it's time to do a clean up
  • => 2FA is enforced, all are reachable, if people want to leave it's possible to do so
• [ 👤 djfe] ramips-mt7621 firmware timeout issue
  • ticket
  • example
• [ 👤 djfe] stability issues on mediatek-filogic