Meeting 2017 01

27.12.2017, 9 participants on site, circa 8 listeners remote via mumble

1. Improving the Gluon maintainer model?

The project is growing, more and more people are contributing, which is awesome! But how to cope with the extra work on the maintainer side? How can we best help Matthias? Is there a way to share the maintenance workload?

Ideas to accelerate gluon development:

• More maintainers/people that can merge:
  • Neoraider is open to give people commit access to the repository
  • He emphasizes that this is not his project, instead it's our project.
  • Everyone with commit access has the same rights (as in LEDE now)
  • If the code quality gets lower (in some borders), it's not that dramatically. More important is that the project continues in it's development.
  • Bugs are tolerable, if they are not happening too often.
  • Result: Also merge what's not perfect yet and improve later.
• Submaintainer per subsystems:
  • Similar to the linux kernel
  • Contra: The project is a lot smaller than the linux kernel
  • Consens to the contra point here. No need for submaintainers.
• Early Merges:
  • It would be desirable, to merge PRs faster as we do now.
  • Packages/features could be marked as experimental.
    • It would not be that problematic, if those packages are broken (even in a release).
    • Maybe the build should fail, when BROKEN=1 is not set and one tries to include experimental packages.
  • Generally it's also not problematic if (non-experimental) packages are broken on the master branch
    • They could be tested before the release is scheduled later.
    • The release checklist should provide a feeling of a guarantee, that the merge is harmless and (potential) issues could be resolved later.
    • The packages should not be obviously (totally) broken.
• General Merge-Policy:
  • A PR can be merged, when it was reviewed by 4 eyes (the creator + one other person)
  • There is no special role for Neoraider here. No need to wait for Neoraider.
• Use of "Help Wanted" flags
  • Case 1: Often PRs fall asleep, because the initiator is no longer doing something (after 2 months PRs should be marked with "Help Wanted" or closed)
  • Case 2: Easy-to-do-PRs should be also marked as "Help Wanted" so newcomers could do them and the others could concentrate on bigger issues.
• Problem of C-Code-Reviewer-Count:
  • Neoraider is currently (nearly) the only person, who reviews C-Code.
  • He encourages the others to review PRs even if they think their review skills are not perfect.
• Developer Meetings
  • Mumble
  • One per month

Ideas to make developing easier

• Writing down guidelines:
  • Guideline: "How to solve problems in the gluon way"
    • Small things:
      • "lua > shell"
      • try to avoid spawning processes in daemons
    • Conceptual things
  • Guideline: Review-Process
  • Checklist before Release
  • Detailed Documentation for the project (no resonance here)
• Those would be TODOs

Reviewing & discussing pending PRs

• gluon-radv-filterd (Jan-Philipp)
  • state: there were some resource issues
  • recently got a review from ecsv
• BABEL+l3roamd (Christof)
  • Discussion on IPvL (IPvLegacy) support:
    • The development of ddhcpd has fallen asleep.
    • Neoraider suggests, that clients do not have to communicate to other clients via IPv4 (it would be enough to communicate via IPv6)
      • We could use xlat464.
      • Each client would get the same IPv4 address.
      • Client isolation would be enabled for IPv4.
      • On the supernode/gateway a na64 daemon would be needed, which can handle that each client has the same IPv4.
      • Roaming in IPv4 is (hopefully) already solved by the IPv6-roaming, since each v4 client has a unique IPv6 assigned
    • Initial babel support will be merged and released without IPv4.
    • Currently Christoph and skorpy are using dns64+nat64 in their babel setup.
      • They incourage to test those setup and write applications which do not work with dns64+nat64 into the wiki
• "Add domain specific configs to gluon" (lemoer)
  • The PR allows building multiple different site configurations into one firmware.
  • Switching between them is currently solved by the scripts in /lib/gluon/upgrade/ which write into the flash. So it's highly undesirable that the domain is changed very often.
  • PR is already tested by kb-light and hexa-.
  • A lot of feedback from neoraider is already implemented.
  • Will be merged soon.
• gluon-hoodselector (Jan-Tarek)
  • Needs adjustments, so it uses the domain api from lemoer instead of hoodfiles.
  • May be greater adjustments because the domain api maybe needs to be extended in a more flexible way, so switching the domain often would be possible.
• gluon-config-mode-geo-locator (Jan-Tarek)
  • With this PR the routers are able to scan the surrounding wifi to determine their location based on external databases.
  • No more information yet, since nobody has reviewed it and Jan-Tarek is not able to speak in mumble.
• gluon-ebtables-limit-arp (Linus)
  • This package should catch at least the heavy ARP-Scans.
  • A daemon in C was written, which updates ebtables rules
  • Problem: currently it talks to batman by spawning batctl as subprocess:
    • Alternative A: directly reading from debugfs - smaller change, for now
    • Alternative B: port the DAT in batman to netlink and use netlink in the daemon - longtime
    • Before the merging alternative A should be fulfilled
  • Problem: ebtables rules are also set via spawing an ebtables subprocess:
    • Alternative A: leave it as it is
    • Alternative B: directly talk to the kernel interface
    • Merging with alternative A is completely fine.
    • Evaluate how ugly the ebtables kernel api is and decide then.
• gluon-alt-esc (Linus)
  • Package that provides a second wifi interface where a local exit gateway could be set.
  • The package works by DNAT on ebtables base
  • Technically and policically not clear. Postponed.

3. Working on pending issues, especially:

• OOM trouble since 2017.x [6] (Martin)
  • Critical issue since LEDE (2017.x)
  • Frequent crashes on 32MB devices
  • The problem is most likely in fq_codel
  • Setting fq_memory_limit to 200 seems to fix the issue
  • Next steps:
    • Test different values for fq_memory_limit
    • Maybe set fq_memory_limit on 32MB devices as a hotfix

4. Not on agenda: Automated Tests

• Pro:
  • Problems in the build process are detected earlier
  • Simple failure scenarios could be detected
• Contra:
  • Additional work
  • Additional infrastructure needed (gluon project has no own infrastructure needs yet)
• (possible) Levels of testing:
  • Automated builds of the master branch
  • Automated builds of PRs
  • Automated testing of the built firmwares in defined test scenarios
• Result of discussion:
  • Automated tests have no priority for us yet, as we have no actual problem to solve.
  • If somebody is interested in helping here: feel free.
  • Some first ideas: Link - Automated tests