-
Notifications
You must be signed in to change notification settings - Fork 325
Roadmap
lemoer edited this page Apr 12, 2022
·
35 revisions
Last updated Gluon Meeting 2022-02 (on 12th April 2022).
This roadmap is not set in stone. It is supposed to give an overview and a basis for discussions of the future development of Gluon.
Especially keep in mind, that this is an OpenSource-Project and there just aren't any ETAs, as it depends on people's goodwill and free time to implement those features.
Here we document, what people are currently working on.
- respondd rework (mkg20001)
- async data fetching (#2467)
- OLSR v1/v2 (#2418 - mkg20001)
- ar71xx -> ath79 Migration (#2413 - aiyion, all)
- Switch to OpenWrt 22.03 (#2426 - neoraider)
- Allow more flexible network setups (#2193 - lemoer)
- RestAPI for Config Mode (#2296 - lemoer)
- usteer in gluon (next-usteer - blocktrron)
Here we moved things from "Currently working on" where people did work on, but the approach went stale.
- XLAT (#1808 - christf)
- Maybe superseeded by this in the future (would be great if OLSR could support it too): https://alioth-lists.debian.net/pipermail/babel-users/2022-March/003895.html
- Babel support (christf)
- Currently no community is actively using the babel features of gluon. So there is no active testing. See here: #2353.
Here we write down ideas there are for the future and nobody picked them up yet.
- "Fallback autoupdater" (also known as Mesh Protocol-independent autoupdater)
- Abbility for clients to fetch an update even if no mesh connection is there, for ex by connecting to FF via Client AP
- New respondd protocol (based on CoAP?)
- New network setup based on network namespaces (for better separation of mesh and WAN on the nodes)
- Issues we hope to solve by using network namespaces: https://github.com/freifunk-gluon/gluon/milestones/network-rewrite
- Single source of truth for config in Gluon
- Avoid upgrade scripts modifying complex UCI configuration, instead regenerate UCI config files on upgrade
- Would require a unified way to allow user to preserve specific config sections, to prevent them from being made less useful by gluon
- Currently network "gluon_preserve" flag
- DFS on 5GHz Mesh, also see:
-
Usage
-
Community
-
Development
- Device Integration
- Roadmap
- Release-life-cycle
- Protocols
- Meeting 2024/06
- Meeting 2024/05
- Meeting 2024/03
- Meeting 2024/02
- Meeting 2024/01
- Meeting 2023/06
- Meeting 2023/05
- Meetup-CCCamp
- Meeting 2023/04
- Meeting 2023/03
- Meeting 2023/02
- Meeting 2023/01
- Meeting 2022/06
- Meeting 2022/05
- Meeting 2022/04
- Meeting 2022/03
- Meeting 2022/02
- Meeting 2022/01
- Meeting 2021/01
- Meeting 2019/01
- Meeting 2018/03
- Meeting 2018/02
- Meeting 2018/01
- Meeting 2017/01
- Concepts
- Release Process
-
Debugging