Hamburg 2019

• happened from June 9th to June 12th at amazing place called Dock Europe, located in Hamburg Altona
• attendees (alphabetical order): aparcar, dangole, Hauke, ​jow, ldir, lynxis, ​neoraider, pepe2k, richb-hanover,​ tmomas, ynezz

• on Monday morning, anyone attending the meeting wrote down arbitrary number of topics to the paper cards
• we've then put those cards on the two boards, merging similar topics together
• as there were a lot of topics, we needed to prioritize, so each attendee got five pins, each of those pins represented one vote, topics with most pins(votes) were discussed first
• topics with no votes were discussed with a soft timer, 6 minutes dedicated to each topic, time was extended as needed

• We would like to create an opt-in statistics feature similar to Debian's popularity contest.
• We must not store any private information, statistics should include only information about the device (model, firmware version, maybe the basic mode it works in - an AP, bridge, etc., list of installed packages, uptime)

• Give users something in return: notification about new firmware version availability
• Combine it with the unattended sysupgrade server

• How to filter out multiple logins from the same device (random “machine id” or “boot id”?)

• Different needs for different users
• Pro-sumers
  • uses the binary releases
  • network engineers
• Professional users
  • build their own
  • mostly use their own Web-UI and not LuCI
    • Luci is too complicated
• Companies who would like LTS support

On Monday, June 10th at around 21:33 CEST, after a short pizza & beer session, lynxis has branched awaited openwrt-19.07.

• Nobody is doing it.
• We should have at least 3 persons who can create a release
• Branches and sub-branches for packages/luci/etc were created
• Documention about creating a new stable is beeing created
• First RC1, targeting stable release in July
• It might be good to have a “release manager”. The person to take care of doing the release or poking people to do so.
• We do not agree on the specific number of releases should we support just one previous stable release, two or even more?
  • should we support just one previous stable release, two or even more?
  • we currently barely have human resources to support just one previous stable release, but the situation might improve once we get out releases every six months
• Future releases now every 6 months, at least a RC
• Point releases every 2 months or sooner in case of CVEs
• We have to take care of ABI stability
• How do we handle CVEs?
• TODO: create shared library versions for libubox

• 6 month release cycle (+ 6 months from date of creating release branch) - “no matter what” approach
  • This implies that not every major OpenWrt release will be based on a new LTS kernel version
• Point release cycle:
  • Every 2 months automatic if there are any new commits within release branch
  • CVE and/or other security fixes ASAP

• There are ways to reduce the image size, but most are hacky and not meant to be enabled by default. Same for memory footprint.
• Don't use kmod, compile them in (saves memory)
  • There is some working proof of concept in Gluon already (add link?)
• Remove opkg
• Under memory pressure, squashfs can run into an “infinite loop”, causing very high load
• JFFS2 requires 5 free blocks to work
• Switch to 4K erase block size (most/all? SPI NOR flash ICs support at least 64 and 4K erase blocks)
• Custom, OpenWrt bootloader
• We will need more space for certain things. e.g. kernel size will increase. But also for hostapd/wpa3 we will need a ssl library.
• Should we add config option like CONFIG_TARGET_BUILD_IMAGE_MIN_SIZE=3900k which would allow us to filter out (using check-size?) devices in TARGET_DEVICES with IMAGE_SIZE below this defined treshold?

• 19.07 will be the last release with support for 4/32 MB devices
• The build bots will not generate images for these devices from master any more, support for these devices would be “source only”
• Support for 4/32 MB devices under DTS-enabled targets would be still accepted
• Patches to improve support for 4 / 32MB devices will still be accepted in master

• News: create a news to say 19.07 will be the last official release supporting 4 MB. Explain why it should not supported. We will merge the 4MB devices into code base, but no longer build images (neither snapshots nor releases) - people will be able to adjust custom builds to fit the image in flash
• Wiki: show a banner in the wiki, DO NOT BUY THOSE DEVICES (tmomas)
  • done, infoboxes have been updated
• How to mark 4MB devices in codebase, use “BROKEN” flag?
• [VOTE] do a vote this release is the last one for 4MB devices

• we should do better on the CI testing field, make it easy to add new unit tests etc.
• automatic build/run testing of developer staging trees would be nice to have
• improve and speed up the review process with automatic PR/patch evaluation
  • a lot of contributions lack formal/basic stuff like SoB, patch description etc.
  • DTS patch/PR submissions contains repeating mistakes which could be automated
• ongoing work on automatic testing directly on the hardware, in the future it should be crowdsourced as kernelci.org for example

• Evaluate GitLab as a replacement for git.openwrt.org, patchworks and the repos on GitHub
  • We have received a positive reference from h01ger, a Debian developer: they have switched to GitLab from SourceForge and are quite satisfied
  • See Introducing freedesktop.org GitLab for another migration story
• Would still support patches via E-Mail
• Replace FlySpray with the GitLab issue tracker which is tightly integrated with commits and merge requests, automatic closing of the issues from the commit messages, API access

• Instead of migrating projects like fw3, procd etc. from git.openwrt.org to GtiHub in order to enable CI testing on CircleCI, setup complete testing environment on Lynxis GitLab instance with external CI runners (ynezz, lynxis, aparcar)

• Announce in Wiki and Forum that we want more people to help out
• Core members should be more direct with asking new people to join the team
• Paul aka aparcar requested to become a member
• richb-hanover to write draft note to send to inactive members <done - see below>
• Motivate the new contributions by the exclusive t-shirt/sticker give-aways

• [VOTE] pepe2k, NeoRaider and ynezz have two new developers in mind to grant commit access
  • voting in progress

• Have a specific list of CVE and packages for one release (similar to sdwalker, but without all packages and only show CVE)
• Have a security mailing list for releases - similar to Debian list
  • Or use a general announcement mailing list
• Do a minimal supported time
• Extended life is another story, we could do the Debian LTS approach if someone wants to support more than 1.5 year
• We agree on stable releases
• We do not agree how much stable releases we should maintain
  • Just 2 (current and previous) or more (maybe 3 which should result in ~1 year time span assuming 6-months release cycle)?
• Supported scope is unclear (core packages, package feed, kernel)?
  • Different parts could have different support times

• A mail should be created with the different opinions to have this discussion with a broader audience on the mailing list (Hauke)
  • Include package feed maintainers
• Who is doing the security mailing list? (lynxis volounteer)

• Create maintainer tools
• Use those maintainer tools to know which package don't have a maintainer
• Use those maintainer tools to nicely ask our maintainers to tell them, you're missing the following things
• Document a golden package and how to do it (partial already there)

• Can we update old base packages (e.g. we have json-c which is outdated)?
• Size might be a quality metric
• We care of size
• We should include size increase of the binaries and packages

• NeoRaider will take care of json-c PR#2024
  • done

• Currently running at chef.libremesh.org
• Nice to have
• Good for new users
• It might need 1 to 2 months until it's ready
• Don't allow to remove core packages
• How to reproduce the image?
• TODO: Make it official when it's ready

• They could fund release maintainership
  • https://www.freexian.com/services/debian-lts.html
• We need to present to them what the OpenWrt community actually needs
• Use them as a communication channel to industry players

• How to do .buildinfo files in OpenWrt?
• h01ger is fine we're using e.g. Debian as base (=if reproducing (initially) needs to be done using the same system, whether Debian or whatever)
• We can reproduce our toolchain based on a commit
• How can we make reproducible-builds.org?
• buildinfo toolchain to describe openwrt.org
• How to supply buildinfo files for packages? Inside the .ipk? Next to it?

• Create a .buildinfo for the toolchain (document the host)
• Create a .buildinfo for packages (containing the openwrt.git & packages.git & [..feed.git] commit hashes and the version

• https://reproducible-builds.org/docs/perimeter/
• https://reproducible-builds.org/docs/recording/ includes links to how this is done in Debian, Archlinux, Tails and the JVM ecosystem. We will happily document with what OpenWrt will come up with.
• https://reproducible-builds.org/docs/definition-strategies/
• https://reproducible-builds.org/docs/formal-definition/
• https://wiki.debian.org/ReproducibleBuilds/BuildinfoSpecification
• PR add buildinfo files https://github.com/openwrt/openwrt/pull/2121

• OpenWrt IRC channel OP: Who has access? How to become OP? Who is the founder?
• How to handle mail aliases?
• How to handle contact@openwrt.org?
  • TODO: jow will create an imap mailbox/reflector to handle contact@openwrt.org
  • This allows us to respond with an official @openwrt.org address
  • TODO: paul and richb will come up with further process steps for handling this address
• TODO: Create a guide line for business guide. What's the high-level process to get a board into OpenWrt?

• How do we handle social media foo?
• Do we want to use big companies platform instead of open source?
• Could we find someone inside the community who would like to become a “PR manager”?
• How could we allow adding of the news content?
  • Could we have for example some repository where we could accept ideas for the news?
• Facebook account?
• Twitter?
  • Use twitter alternative (mastodon)?

• Create library version for “our” packages (libubox, …)
  • Like branching, just do it
• Add source package name to opkg metadata in order to be able to parse the ABI version properly

• Merge PR which adds support for REQUIRED_SIGNATURE
• Make signing of sysupgrade images working on the buildbots
• Enable REQUIRED_SIGNATURE=1 on ath79 for testing ASAP in order to iron out all possible bugs before the next release

• Document the OpenWrt specific internals like boot process, procd, ubus, uci, sysupgrade etc.
• Targeted more towards developers, should be included in the tree, Linux kernel is considered as a good example
• respin https://lede.readthedocs.io/en/latest/ idea?
  • https://lists.openwrt.org/pipermail/openwrt-devel/2017-November/009888.html

• jow is willing to start working on this ASAP and provide actual content, but in order to make it easier for him, he would like to have some structured TOC first (ask bobafetthotmail for the help?)

• Enable 4.19 on all targets which already have 4.19 support ASAP in order to start testing
• In order to encourage focus on ath79 and to make the transition period more easier for the downstream projects were not going to remove ar71xx from the tree yet, but we will mark the target as “source only” and don't produce any binary images anymore, remove the target from the tree in the next release

• Create firewall4 which would just use current UCI config for firewall3 and generate the script which would be used by the nftables CLI tools
• Later it could be optimized, CLI tools could be replaced with libnftables

• Try to find out some online service used by other open source projects

• rpcd based, less Lua code on the backend, shell script based middle layer
• Document rpcd API in order to allow more contributions from frontend developers
• Consider abandoning of the current UCI editor approach towards UCI config generator
• Provide use case based wizards targeted for specific groups, like home users, network admins etc.
  • Should provide much more simpler UI, like guest SSID wizard etc.

• Define clearly what package should be included in the master tree
• Do we really need packages like for example OpenVPN or Wireguard in the master tree?
  • There might be other packages as well which could be probably moved into the packages feed

• Basically looks like unmaintained
• A lot of lingering PRs and issues some of them for more then 4 years

• Approach routing feeds maintainers and propose solution (lynxis)
  • aparcar (paul) has already started the process

• Start adding RAM variable along the IMAGE_SIZE to the image Makefiles
  • (TODO: add the reason for this need)
• YAML based TOH in the tree, should be part of the patch which adds new device to the tree, which should replace current mandatory description of the device/flashing instructions in the commit message
• TODO: Provide package/script which could be run on the device and which could pre-populate the YAML file with the runtime based information (aparcar)

• An unfair advantage is any feature or capability that is so cool that others, especially competitors, say “Hey - that is not fair!”
• OpenWrt powers tens of millions of home routers, either directly, or through other vendors that incorporate the OpenWrt technology into their routers
• X million other embedded Linux devices that run OpenWrt or a derivative
• OpenWrt is stable, maintained by a team of Y professionals over a period of Z years
  • <Help me if I am making up too much stuff here… Pull me off the wires! richb-hanover>
• OpenWrt is available on eleventy-seven architectures supporting dozens of variations
• OpenWrt currently supports over a bazillion different products
• The OpenWrt team consists of lots and lots of core developers, with a bunch more package maintainers
• The OpenWrt development environment rebuilds the full code body every night for every architecture, so that there is always a build available to test
• The OpenWrt build system also runs a series of automated tests to ensure code quality: code coverage, notifications on build errors, notifications of relevant CVEs, what else?

• Create something exclusive we could give away as a thank you to the contributors
  • First 10 commits in the project etc.
• Decide how to get the design, should it be some kind of community contest/voting
  • Or just approach some specific/selected graphic designer/company
• Decide how to handle the distribution

• There should be some goals defined which we would like to get into the next release
  • Improve security aspects (ujail, seccomp etc.)
  • Migrate buildroot to Python3
  • Aim for 100% reproducible builds at least on most popular targets

• Our current rules tie voting right to the ability to commit access to master
  • This was a useful concept in the early days
  • This can lock out package maintainers, community stakeholders, forum/wiki maintainers as the number of roles in OpenWrt increases
  • We will need to redefine the rules that apply to various roles in the project

• [VOTE] Vote on putting wiki people onto the contact address

• Unify/refresh/modernize the look/presentation of the project to the outside world
• Refresh logo, provide official vector version usable on stickers, t-shirts etc.
• Project color guidelines etc.

Solved via new OpenWrt logo usage and guidelines, winner of the voting.

• Refresh the style with the modern looking Bootstrap based theme (tmomas)
• Issue with bootstrap theme is finally fixed → Bootstrap theme can now be used
• Howto: Wiki style refresh

• [VOTE] Consensus of this meeting was to proceed, needs approval from the full group

• Meet periodically every 6-9 months
• There was a discussion of possibly meeting again in Barcelona in February 2020

Paul & Jo will touch base with ? to see if there might be a venue at BCP

• Were still missing formal definitions for a lot of processes