Meeting notes - 30th November 2022 virtual meeting

Participants: Paul, Hauke, Ansuel, pepe2k, ynezz, wigyori, svanheule, Rafal, Daniel, stintel, lynxis, zorun

  • consider adding a stale bot to flag issue stale for more than a year?
  • a too big number may put wrong ideas for new users about the project
  • on the other hand, auto-closing valid bugs without any developer feedback is demotivating, and it prevents other people from finding existing bugs
  • no consensus on auto-closing bugs
  • Ansuel/Paul/Lynxis will manually do some sorting of very old bugs (18.06-related)
  • we will look into using Github issue templates to better triage bug reports and ideally add automatic labeling (feature/bug/etc)

wolfssl vs. openssl vs. mbedtls

  • only part of wolfssl ABI is stable
  • only major versions releaes
  • package sizes:
    • wolfssl (~540KB)
    • openssl (~1000KB)
    • mbedtls (~240KB)
  • openssl 1.1.1 EoL in September 2023, we have to upgrade to openssl 3.0
  • mbedtls: no hostapd and TLS 1.3 support
  • ideas:
    • have openssl on targets with big flash (~128MB) and use mbedtls on devices with small flash
    • Maybe drop WPA3 and TLS support on small flash devices (~8MB)
    • Daniel want to look into this
  • GCC 11.x to 12.X
    • has some strange compiler warnings / errors with some packages
    • supports eBPF (and BTF which was previously missing), maybe allows us to drop LLVM
  • Create ticket to track GCC problem
  • binutils 2.37 to 2.39
  • Maybe have a release team?
  • If something is in the release process looks stuck ask in IRC, sometimes people are busy with other topics
  • We should mention that 23.XX will be the last release to support 8 MB flash devices
Does not look good

GitHub PRs: Patchwork:

  • lack of developers to review contributions
  • some pull requests are adding hardware but nobody has the hardware and the skills to build an image
  • We should improve our pull request handling
  • Maybe more automated checks
  • close abandoned pull requests
  • close pull requests that are not acceptable instead of ignoring them
  • be less strict about quality of PR adding new devices (e.g. not care about empty lines in DTS)
  • use the CI to build working images for PR adding new devices
  • SFC recommends to give up GitHub:
  • other reasons against GitHub given in mailinglist, i.e.
  • Adrian was initially against Gitea due to worse PR review workflow. Possible changed within the last two years. Should be evaluated again.
  • Stintel started experimenting with Codeberg CI (Woodpecker CI)
  • poll “Look more into Codeberg”: 7 in favour, 2 against, 3 no opinion
  • Idea from Daniel: look at Codeberg to replace Patchwork (to have CI for patches), but continue using Github (for now)
  • Result: OK to continue looking at Codeberg, but no big pool or announcement about it yet
  • make public our prebuilt tool container? (alternative to an hacked sdk?)
  • Stintel is working on it, will send an annoucement soonish

mvebu has completely broken switch/DSA/VLANs

  • With kernel 5.15 the problem is fixed
  • Turris is using kernel 5.15
  • make these devices source-only in the 22.03 branch, AND possibly remove existing download files for 22.03.X releases (to be discussed on mailing list)
  • only remove firmware files but leave packages for users.
  • ynezz will send a patch on the ML

We got offer for 2 systems for builds, either our m3.small or our older c2.medium type

  • some members have objections as well
  • ynezz will send a mail to the company and kindly reject the offer

Qarnot is a French company

  • their business is to provide bare metal servers for heavy compute tasks (they heat water with it)
  • they are using OpenWrt internally and are open to provide workers (in exchange for visibility)
  • exact technical setup TBD (Bare metal access, Docker, Buildbot integration) but should be feasible

no objection, zorun will send an email on openwrt-adm to see if other people object

There are currently multiple approaches to manage and control PoE on different devices and chips. Instead there should be a unified solution.

People are actually working on it, give it more time

  • Not many people voted to add RobiMarko as new member
  • Discussion about the existing rules
    • How to interpret “unreachable for 3 months”
    • Our rules specify votes are with “simple majority” (50% of people who vote, ignoring people that don’t vote), but in practice we apply “super majority” (50% of all people with voting rights)
    • For new members, if even 1 or 2 persons vote No, then we should probably take it into account and not accept the new member
    • Should we require disclosing the reasons for refusing a new member? Probably only internally among project members, not publicly, because it can harm the reputation of the person. Also it’s difficult to disclose personal reasons.
  • write a proposal for updates rules in a pad
    • Paul + Hauke will propose something
    • review by ansuel, stintel, pepe2k, wigyori, baptiste
  • later popose on mailing list for further discussions
  • in the end have a vote using old rules
  • Maybe for new members max 3 negative votes

Is it OK if OpenWrt developers to individually apply for funding at NLNet etc?

  • It’s fine if it’s clearly presented as an individual application and that the person is not endorsed by the OpenWrt project
  • Please share on the mailing list if an application is successful to have an overview of what projects are being worked on
This website uses cookies. By using the website, you agree with storing cookies on your computer. Also you acknowledge that you have read and understand our Privacy Policy. If you do not agree leave the website.More information about cookies
  • Last modified: 2022/12/01 19:36
  • by aparcar