Meeting notes - 20th September 2021 virtual meeting

Date: 20th September 2021

Participants: stintel, Hauke, Adrian, lynxis, thess, lach1012, daniel, wigyori, paul, Richb, rsalvaterra, tmomas, mkresin, Imre

Notes:

• Richb: went well
  • There was more work than we expected
• Hauke: went well, but too much unplanned work still needed to stabilize and finish.
• Daniel: we did better QA compared to 19.07
• rsalvaterra: underestimated the efforts to convert to DSA
• Hauke: more RCs was good
• Adrian: missing parts in LuCi was a vital problem (particularly DSA)
• missing some overview what is missing for the release
  • Richb: wiki page about release state hard to find[1], maybe introduce roadmap page? https://openwrt.org/docs/guide-developer/releases/goals/21.xx
  • lynxis: mark issues for release and manage them, maybe release manager role?
    • maybe use the priority of the issue tracker
• rsalvaterra: we have a systemic problem with documentation…
  • wiki often very outdated
  • doing documentation is boring
• Richb: it [documentation] is hard to do.

• Hauke: 19.07 suggested EOL beginning of March 2022.
• last build in march 2022 and then EOL
• announce now

• kernel 5.10
  • https://www.mail-archive.com/openwrt-devel@lists.openwrt.org/msg59667.html
  • Regenerated: https://zerobin.fff.community/?79235be857101efb#UlXS1vbLPtnfd76F225ZZM31itB28CD4PklytdK21Z8=
• musl 1.2
• Update to GCC 11.2 and binutils 2.37? rsalvaterra: should be fine since this morning :)
• firewall4? ⇒ move to nftables
  • works with old config, but not with custom commands
  • will certainly break a bunch of things
• mac80211 update to 5.15

• Who will take care?
• Focus primarily on bug fixing and hardening + regression testing?

Notes:

• lynxis: Not using the current date as version number, but a date some months in the future as release version.
• Do we only do small changes like kernel + toolchain update without big new features or big changes?
• The updates (toolchain, kernel, mac80211) are not a problem for master + next release, firewall4 we are unsure.
• Hauke: TODO write mail about next release: status of Luci, wiki page or pad
• rsalvaterra: some ath79 boards will likely get DSA e.g. qca8k

• Imre: Timed releases would be better like Ubuntu or the kernel do it. Industry is using snapshots because we are not doing new releases fast enough
  • others: It took about 6 months to get 21.02 stable
  • more releases is probably not possible, because it causes too much effort, it would be helpful if industry would help

• wait till after we branch with integration?
• How long do we keep 5.4 around?

Notes:

• If we branch this year wait with 5.15 till after we branched off, otherwise talk again
• why are kernel updates needed?: lots of activities in network part, we have a lot of backport patches already.
• We remove the generic 5.4 support when the last target switched. The target patches can get removed before.

• Pending pull request on github (~216) and open patches in patchwork
• Getting more people in
  • Getting inactive people out (reaching quorum becomes harder and harder)

Notes:

• wigyori: was better when we had maintainers
  • Adrian: we would probably not find anyone for ipq* targets for example
• for people who dislike web based stuff, have you tried https://cli.github.com/ ?
• more test automation
  • we have multiple proposals which are partly deployed
  • Paul: experimental images for others to test
  • lynxis: we already merge devices without runtime testing, but it only breaks this single board
  • buildbot/ CI on staging trees.
  • Imre: Run test changes on at least two different targets
• Richb: releasing more often also allows us to break things in the development branch without hurting people who have started using that in production (which they shouldn't, but maybe did due to lack of choice)

• problem is not contributors, but reviewers?.
• voting problem:
  • Adrian: have a relative majority
  • Imre: limit it to e.g. 1 week

• Idea behind Freescout: easy standard responses with central tracking
• If there are no objections, we can change the contact@ address to no longer forward to all of us, but arrive in Freescout instead. As we will no longer have an address that forwards to everybody, I suggest to create a new alias for this. However, to avoid cold-mailing to random addresses, I suggest to use a random suffix, so the address would become something like everyone-3coei5gz16uesmdu@openwrt.org. This to avoid any kind of spam, so there is no need to filter mails sent to this address to a separate folder or /dev/null, and we avoid the risk that some people will never read any mail sent to this address.

Notes:

• Why cant we have both:
• We do not get the notification in contact@ if it was send over freescout
• many emails which do not get an answer are stupid support requests
• improve spam filtering and keep both
• make freescout send contact@ into CC
• paul: have one manager to take care of this:
  • other: this will not work

• postpone

• How to decide which features to include when
• Focus on ensuring that existing feature set is working, keeps working and is at least rudimentary documented
• Who has an automated test setup which can do more than booting?

• having separate mailing list for infra
• Ted and stintel want to take care of infra, but they do not know how the build infrastructure works.
• Release management committee?
• If you want to start a committee, just propose one

• ath10k and ath10k-ct are unusable and fixes very unlikely
• imo (stintel) we should remove all ath10k devices from any recommended hardware list and even stronger, write about the fact that qca doesn't give a damn and suggest people not to buy anything qca based at all
• mt76 stability issues rmilecki - how can we make sure they are looked into and hopefully solved?

• what to do about ath10k?
• still recommend it?

• as we grow, I think it makes sense to create a few committees, e.g. infra, security committee
• these committees can ideally decide on some topics assigned to them without requiring voting
  • periodic maintenance on infra once every month
  • move to managed mysql/postgres
  • move to managed k8s instead of running Linux + Docker
• can meet on their own, making it easier to setup meeting with all committee members
• different mailboxes / freescout, e.g. infra@ for mailings from DO, ..

• having separate mailing list for infra
• Ted and stintel want to take care of infra, but they do not know how the build infrastructure works.
• Release management committee?
• If you want to start a committee, just propose one

• workshop similar to hamburg “meeting”
• about 50% people of the people are interested

A dedicated VM runs a server instance and can be accessed via the following address:

https://sysupgrade.openwrt.org/

To use the server either luci-app-attendedsysupgrade (LuCI) or auc (CLI) should be installed.

The server source code is available on GitHub:

https://github.com/aparcar/asu/

(Demo: downloads.asu.aparcar.org/)

• have a next meeting next month
• have it every month