Meeting 2024 02

Gluon Meetup 2024-02

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

Notes from Last Meetup: Meeting-2024-01

Attendees

• [ 👤 Djfe]
• [ 👤 T_X]
• [ 👤 maurerle]
• [ 👤 neocturne]
• [ 👤 rotanid]
• [ 👤 tomh]

Topics

Please always note your name next to your topic

• New Version Scheme Part 2
  • [ 👤 grische] If "v2023.1" and "v2023.2" are too close together, why not use the Ubuntu naming scheme "YEAR.MONTH" and then have a patch version, totalling to YEAR.MONTH.PATCH. This won't conflict with the existing scheme and seems to address all concerns brought up last time.
    • [ 👤 neocturne] The reason why a new scheme was proposed is that the release name 2023.2 had become outdated because the release was delayed until 2024. Also including a month would mean that release names can become outdated every month. Concerns regarding releases being more or less close were mostly about development progress (big features and major OpenWrt updates), not about time
    • this topic is currently not crucial as no release is scheduled - so the topic is delayed until the next meeting
• [ 👤 neocturne] Development branch name
  • OpenWrt recently added a main branch that is kept in sync with the master branch
  • For Gluon, I propose to just rename master to main - Github will handle updating all existing PRs automatically. Communities would have to update their build setup if they automatically build from master (I think? I don't think Github will redirect the branch access?)
  • no decision in this meeting (but no objection from attendees)
  • [ 👤 maurerle] should be no problem due to github automatically redirecting renamed branches: https://github.blog/changelog/2020-07-17-links-to-deleted-branches-now-redirect-to-the-default-branch/
  • should be done using the rename UI: https://github.com/github/renaming?tab=readme-ov-file#renaming-existing-branches
  • [ 👤 rotanid] should be done in all repositories
• [ 👤 tomh] nftables migration
  • any progress? current state? plan moving forward?
  • [ 👤 neocturne] currently no progress, current state still works with latest OpenWrt, so no pressure at this moment
  • [ 👤 neocturne] fw3 will be replaced one day, currently unclear whether by fw4 or by a separate abstraction layer
• [ 👤 T_X] brmldproxy: review, merge?
  • https://github.com/freifunk-gluon/gluon/pull/2995
  • https://github.com/freifunk-gluon/packages/pull/264
  • we should not add more non-backport patches to gluon
  • [ 👤 maurerle] people can use the repo and instructions posted here instead to test: https://forum.freifunk.net/t/gluon-multicast-peering-routing-tester-gesucht/23982
• [ 👤 T_X] batman-adv: bump to v2024.1 for new multicast packet type?
  • this feature needs all nodes to be updated, so would be useful to start deployment early
  • already deployed at FFHL and one domain at FFV
• [ 👤 T_X] Anyone at Wireless Battlemesh v16 + OpenWrt Summit 2024? :-) - May 15 - 19, 2024, Cyprus
• [ 👤 T_X] GSoC 2024 status: currently one student for one Gluon related project: SSID changer update
• [ 👤 maurerle] documentation update
  • https://github.com/freifunk-gluon/gluon/pull/3188
• [ 👤 maurerle] https://github.com/freifunk-gluon/gluon/issues/3173
  • should this be closed or not? - not closing for now