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)

• Kernel 5.15 status: https://github.com/openwrt/openwrt/issues/10672
• mac80211 update to kernel 6.1

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
  • RFC mbedtls support for hostapd https://github.com/openwrt/openwrt/pull/10727
• 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: https://github.com/openwrt/openwrt/pulls Patchwork: https://patchwork.ozlabs.org/project/openwrt/list/

• 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
  • We already build automatically
    • This will build target which changed: https://github.com/openwrt/openwrt/pull/11171
  • Maybe check dts files automatically?

• 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: https://sfconservancy.org/GiveUpGitHub/
• other reasons against GitHub given in mailinglist, i.e. https://lists.openwrt.org/pipermail/openwrt-devel/2022-January/037643.html
• 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

• relevant discussion: http://lists.openwrt.org/pipermail/openwrt-devel/2022-August/039247.html
• probably not legal - delete from tree or ask SFC for advice first?
• fman-ucode: https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=package/firmware/layerscape/fman-ucode/Makefile;h=0d2ae68283040a392f368b183d343ab9ff83c6b1;hb=HEAD https://github.com/NXP/qoriq-fm-ucode/blob/integration/NXP-Binary-EULA.txt
• ppfe: https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=package/firmware/layerscape/ppfe-firmware/Makefile;h=80aa15d67ae91f9ba4210583ca95368223d1cb60;hb=HEAD https://github.com/NXP/qoriq-engine-pfe-bin/blob/integration/NXP-Binary-EULA.txt
• probably everything under package/firmware/layerscape, possibly others
• add checks for PKG_LICENSE, if not whitelisted: do not include package in buildbot builds, maybe behind a config option like BUILD_PATENTED - could also be used for Raspberry Pi Zero 2 W wireless firmware - individual licenses could be added to whitelist as we get approval from SFC
• add license file into ipkg, this is required by many licenses also from linux-firmware
• We should go through all firmware files we package and check for this
• If redistribution is not allowed by a firmware license we can not integrate it into OpenWrt. OpenWrt ships binaries and redistributes firmwares
• Stintel volunteers to lead this firmware clarification effort (in particular with SFC)

• 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

• https://github.com/openwrt/openwrt/issues/10997
• https://github.com/openwrt/openwrt/issues/11077
• https://github.com/openwrt/openwrt/issues/10628
  

• 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

• https://deploy.equinix.com/product/servers/m3-small/
• https://deploy.equinix.com/developers/docs/metal/hardware/legacy-servers/#c2mediumx86 (seems like a best offer)

• “I advise to not accept this from Equinix for the bad they have been doing in the interconnection market in different places.”
• http://lists.openwrt.org/pipermail/openwrt-devel/2022-November/039852.html

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

Qarnot is a French company https://qarnot.com/en

• 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

• https://twitter.com/netdev01/status/1585980306104160256

• Not many people voted to add RobiMarko as new member
• Discussion about the existing rules https://openwrt.org/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