Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision Next revisionBoth sides next revision | ||
| meetings:hamburg2019:start [2019/07/09 23:54] – [T-shirts and stickers] pepe2k | meetings:hamburg2019:start [2020/02/06 19:05] – [Wiki style refresh] Issue with bootstrap theme is finally fixed tmomas | ||
|---|---|---|---|
| Line 4: | Line 4: | ||
| * happened from **June 9th** to **June 12th** at amazing place called [[http:// | * happened from **June 9th** to **June 12th** at amazing place called [[http:// | ||
| - | * **attendees (left to right):** aparcar, ldir, richb-hanover, dangole, Hauke, | + | * **attendees (alphabetical order):** aparcar, dangole, Hauke, |
| ===== Agenda preparation ===== | ===== Agenda preparation ===== | ||
| Line 97: | Line 97: | ||
| * 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 | * 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) | + | * <del>Wiki: show a banner in the wiki, DO NOT BUY THOSE DEVICES (tmomas)</ |
| + | * done, [[meta: | ||
| * How to mark 4MB devices in codebase, use " | * How to mark 4MB devices in codebase, use " | ||
| * **[VOTE]** do a vote this release is the last one for 4MB devices | * **[VOTE]** do a vote this release is the last one for 4MB devices | ||
| Line 112: | Line 113: | ||
| ===== Defragmentation of Code and Tools ===== | ===== Defragmentation of Code and Tools ===== | ||
| - | * Evaluate GitLab as a replacement for git.openwrt.org, | + | * Evaluate GitLab as a replacement for git.openwrt.org, |
| * We have received a positive reference from h01ger, a Debian developer: they have switched to GitLab from SourceForge and are quite satisfied | * We have received a positive reference from h01ger, a Debian developer: they have switched to GitLab from SourceForge and are quite satisfied | ||
| * See [[https:// | * See [[https:// | ||
| * Would still support patches via E-Mail | * Would still support patches via E-Mail | ||
| - | * Replace FlySpray with the GitLab issue tracker which is tighly | + | * Replace FlySpray with the GitLab issue tracker which is tightly |
| ==== TODO ==== | ==== TODO ==== | ||
| - | * instead | + | * Instead |
| ===== New People ===== | ===== New People ===== | ||
| - | * Annouce | + | * Announce |
| * Core members should be more direct with asking new people to join the team | * Core members should be more direct with asking new people to join the team | ||
| * Paul aka aparcar requested to become a member | * Paul aka aparcar requested to become a member | ||
| Line 133: | Line 134: | ||
| * **[VOTE]** < | * **[VOTE]** < | ||
| - | * [[http:// | + | * <del>[[http:// |
| ===== Stable discussion ===== | ===== Stable discussion ===== | ||
| - | * have a specific list of CVE and packages for one release. (similar to sdwalker, but without all packages and only show CVE) | + | * 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 | + | * Have a security |
| - | * or use a general announcement mailing list | + | * Or use a general announcement mailing list |
| - | * do a minimal supported time | + | * Do a minimal supported time |
| - | * Extended life is another story. we might could do the Debian LTS approach if someone | + | * Extended life is another story, we could do the Debian LTS approach if someone |
| - | * we agree on stable releases | + | * We agree on stable releases |
| - | * we do not agree how much stable releases we should maintain | + | * We do not agree how much stable releases we should maintain |
| - | * Supported scope is unclear? (core packages, package feed, kernel) | + | * Just 2 (current and previous) or more (maybe 3 which should result in ~1 year time span assuming 6-months release cycle)? |
| - | * different | + | * Supported scope is unclear (core packages, package feed, kernel)? |
| + | * Different | ||
| ==== TODO ==== | ==== TODO ==== | ||
| - | * a mail should be created with the differnt | + | * A mail should be created with the different |
| - | * include | + | * Include |
| - | * who is doing the security | + | * Who is doing the security |
| ===== Package maintainer ===== | ===== Package maintainer ===== | ||
| - | * create | + | * Create |
| - | * use those maintainer tools to know which package don't have a maintainer | + | * 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. | + | * Use those maintainer tools to nicely ask our maintainers to tell them, you're missing the following things |
| - | * document | + | * Document |
| ===== Deprecated packages ===== | ===== Deprecated packages ===== | ||
| - | * can we update old base packages? e.g. we have json-c which is outdated. | + | * Can we update old base packages |
| - | * size might be a quality metric | + | * Size might be a quality metric |
| - | * we care of size | + | * We care of size |
| - | * we should include size increase of the binaries and packages | + | * We should include size increase of the binaries and packages |
| ==== TODO ==== | ==== TODO ==== | ||
| Line 173: | Line 175: | ||
| ===== Online Image Builder ===== | ===== Online Image Builder ===== | ||
| - | * currently | + | * Currently |
| - | * nice to have | + | * Nice to have |
| - | * good for new users | + | * Good for new users |
| - | * it might need 1 to 2 month until it's ready | + | * It might need 1 to 2 months |
| - | * don't allow to remove core packages | + | * Don't allow to remove core packages |
| - | * **TODO:** make it official when it's ready | + | |
| * How to reproduce the image? | * How to reproduce the image? | ||
| + | * **TODO:** Make it official when it's ready | ||
| ===== prpl Relationship ===== | ===== prpl Relationship ===== | ||
| - | * they could fund release maintainership | + | * They could fund release maintainership |
| - | * we need to present to them what the OpenWrt community actually needs | + | * [[https:// |
| - | * use them as a communication channel to industry players | + | * We need to present to them what the OpenWrt community actually needs |
| - | * [[https:// | + | * Use them as a communication channel to industry players |
| ===== Reproducible Builds ===== | ===== Reproducible Builds ===== | ||
| - | * how to do .buildinfo files in OpenWrt? | + | * How to do .buildinfo files in OpenWrt? |
| - | * h01ger is fine we're using e.g. debian | + | * h01ger is fine we're using e.g. Debian |
| - | * we can reproduce our toolchain based on a commit | + | * We can reproduce our toolchain based on a commit |
| - | * how can we make reproducible-builds.org? | + | * How can we make reproducible-builds.org? |
| * buildinfo toolchain to describe openwrt.org | * buildinfo toolchain to describe openwrt.org | ||
| - | * how to supply buildinfo files for packages? | + | * How to supply buildinfo files for packages? |
| ==== We need to recreate the same toolchains ==== | ==== We need to recreate the same toolchains ==== | ||
| - | * create | + | * Create |
| - | * create | + | * Create |
| ==== Useful documentation related to .buildinfo files ==== | ==== Useful documentation related to .buildinfo files ==== | ||
| Line 213: | Line 215: | ||
| ===== Remaining of lede-project merge? ===== | ===== Remaining of lede-project merge? ===== | ||
| - | * OpenWrt | + | * OpenWrt |
| - | * how to handle mail aliases? | + | * How to handle mail aliases? |
| * How to handle contact@openwrt.org? | * How to handle contact@openwrt.org? | ||
| * **TODO:** jow will create an imap mailbox/ | * **TODO:** jow will create an imap mailbox/ | ||
| * This allows us to respond with an official @openwrt.org address | * 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:** paul and richb will come up with further process steps for handling this address | ||
| - | * **TODO: | + | * **TODO: |
| ===== Social things ===== | ===== Social things ===== | ||
| Line 227: | Line 229: | ||
| * Could we find someone inside the community who would like to become a "PR manager"? | * Could we find someone inside the community who would like to become a "PR manager"? | ||
| * How could we allow adding of the news content? | * How could we allow adding of the news content? | ||
| - | * could we have for example some repository where we could accept ideas for the news? | + | * Could we have for example some repository where we could accept ideas for the news? |
| - | * facebook | + | * Facebook |
| - | + | * Twitter? | |
| - | * use twitter alternative ([[https:// | + | * Use twitter alternative ([[https:// |
| ===== Library versioning ===== | ===== Library versioning ===== | ||
| - | * create | + | * Create |
| - | * like branching, just do it. | + | * Like branching, just do it |
| - | * add source package name to opkg metadata in order to be able to parse the ABI version properly | + | * Add source package name to opkg metadata in order to be able to parse the ABI version properly |
| ===== Signing of sysupgrade images ===== | ===== Signing of sysupgrade images ===== | ||
| - | * merge PR which adds support for '' | + | * Merge PR which adds support for '' |
| - | * make signing of sysupgrade images working on the buildbots | + | * Make signing of sysupgrade images working on the buildbots |
| - | * enable | + | * Enable |
| ===== Create a manual ===== | ===== Create a manual ===== | ||
| - | * document | + | * Document |
| - | * targeted | + | * Targeted |
| * respin [[https:// | * respin [[https:// | ||
| * [[https:// | * [[https:// | ||
| Line 257: | Line 259: | ||
| ===== Switch to next stable kernel 4.19 ===== | ===== Switch to next stable kernel 4.19 ===== | ||
| - | * enable | + | * Enable |
| - | * 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 " | + | * 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 " |
| ===== Switch to nftables ===== | ===== Switch to nftables ===== | ||
| - | * create | + | * Create |
| - | * later it could be optimized, CLI tools could be replaced with libnftables | + | * Later it could be optimized, CLI tools could be replaced with libnftables |
| ===== LuCI translations ===== | ===== LuCI translations ===== | ||
| - | * try to find out some online service used by other open source projects | + | * Try to find out some online service used by other open source projects |
| ===== LuCI future ===== | ===== LuCI future ===== | ||
| * rpcd based, less Lua code on the backend, shell script based middle layer | * rpcd based, less Lua code on the backend, shell script based middle layer | ||
| - | * document | + | * Document |
| - | * consider | + | * Consider |
| - | * provide | + | * Provide |
| - | * should | + | * Should |
| ===== Review base packages ===== | ===== Review base packages ===== | ||
| - | * define | + | * Define |
| - | * do we really need packages like for example OpenVPN or Wireguard 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 | + | * There might be other packages as well which could be probably moved into the packages feed |
| ===== Approach routing feed ===== | ===== Approach routing feed ===== | ||
| - | * basically | + | * Basically |
| - | * a lot of lingering PRs and issues some of them for more then 4 years | + | * A lot of lingering PRs and issues some of them for more then 4 years |
| ==== TODO ==== | ==== TODO ==== | ||
| - | * <del>approach | + | * <del>Approach |
| * aparcar (paul) has [[https:// | * aparcar (paul) has [[https:// | ||
| ===== New table of hardware (TOH) ===== | ===== New table of hardware (TOH) ===== | ||
| - | * start adding RAM variable along the IMAGE_SIZE to the image Makefile | + | * Start adding RAM variable along the IMAGE_SIZE to the image Makefiles |
| * (**TODO:** add the reason for this need) | * (**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/ | * 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/ | ||
| - | * **TODO: | + | * **TODO: |
| ===== The OpenWrt Unfair Advantage ===== | ===== The OpenWrt Unfair Advantage ===== | ||
| Line 309: | Line 311: | ||
| * OpenWrt is available on eleventy-seven architectures supporting dozens of variations | * OpenWrt is available on eleventy-seven architectures supporting dozens of variations | ||
| * OpenWrt currently supports over a bazillion different products | * OpenWrt currently supports over a bazillion different products | ||
| - | * The OpenWrt team consists of lots and lots of core developers, with a bunch more package | + | * The OpenWrt team consists of lots and lots of core developers, with a bunch more package |
| * The OpenWrt development environment rebuilds the full code body every night for every architecture, | * The OpenWrt development environment rebuilds the full code body every night for every architecture, | ||
| * 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? | * 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? | ||
| Line 339: | Line 341: | ||
| * **[VOTE]** Vote on putting wiki people onto the contact address | * **[VOTE]** Vote on putting wiki people onto the contact address | ||
| - | ===== Refresh | + | ===== Refresh project identity ===== |
| * Unify/ | * Unify/ | ||
| Line 348: | Line 350: | ||
| * Refresh the style with the modern looking Bootstrap based theme (tmomas) | * Refresh the style with the modern looking Bootstrap based theme (tmomas) | ||
| + | * [[https:// | ||
| ==== TODO ==== | ==== TODO ==== | ||