[Question] Who is the Documentation Maintainer in Zephyr?
By the next LTS (to include licensing modules)
Modules - Testing
Testing modules’ code
HALs: implicitly tested via Zephyr test running on targets
Libraries, tools, etc: we will provide integration testing
Basic samples, tests, developed by Zephyr, residing in Zephyr tree
Covering basic use configurations of the module integrated to Zephyr
Requirements for module integration testing on a case-by-case basis
Certain modules have upstream tests
Upstream module tests explicitly written for Zephyr, could potentially be added in our testing
Adding a new module
Module candidate: a project with its own life-cycle outside Zephyr (not written exclusively for Zephyr)
We should have a checklist for accepting a new module
Depreciate, and Remove modules
Generic policies for depreciation
List depreciate status in module metadata
Reasons may vary
Modules - Security
Aware of upstream project security issues and monitoring fixes
Update to latest versions before releasing Zephyr
Won’t perform scanning on modules’ code
Continue discussion for 1-2 more meetings of the Process forum
Offline review of Draft
TSC to vote for the proposal?
[David B] How do we manage security vulnerabilities?
[Ioannis] Linking to existing security vulnerabilities in the upstream project (if it is present)
[Ioannis] Be aware and monitor fixes -- responsibility of module owner
Good to have centrally located and pending PR is #24152.
YML + script which assigns code reviewers and PR.
Need to check and TSC approve terminology in YML
No objections to ARC architecture maintainer
No objections to Bluetooth collaborators
No objections to Bluetooth controller collaborators
[Anas] Are the maintainers and collaborators still on-board with maintaining?
[Ioannis] Will follow up with folks after we’re OK with folks
Devicetree maintainers? Remove ulfalizer? Yes, we can always add back.
[David Leach] Only maintainer needs TSC approval. Collaborators can be added by maintainers.
Do full review of the file once a year.
Documentation: Carles as maintainer? Doxygen might be too much but happy to maintain .rst. No TSC objections.
[Kumar] Subsystem docs should be owned by the subsystem maintainer and not the documentation maintainer.
Cannot scale having a doc maintainer review all PRs that change any doc.
Drivers: ADC: anangl as maintainer? No objections.
Drivers: Clock control: Christof (handle?)? Need to reach out. No TSC objections
Drivers: Console: pfalcon? [Kumar] Would list as unmaintained.
Drivers: Crypto: Any ideas?
Drivers: DAC: Need to add to YML. Martin Jaegar. Alexander Wachter says Martin would accept.
Drivers: DMA: Any ideas?
Drivers: EEPROM? Henrikbrixandresen? No objections but need to confirm with them.
Drivers: Entropy? Flavio? No objections. Intel?
Drivers: ESPI? Anas? Intel? MicroChip?
Drivers: Ethernet: tbursztyka. Jukkar and pfalcon ok as collaborators.
Drivers: GPIO: mnkp plus any others
Should maintainers be singular? Yes, maybe. Collaborators can be added by the maintainer to help share review load without needing TSC approval.
Drivers: HW Info: alexanderwachter? Yup, ok doing it and no TSC objections.
Drivers: I2C: Marti Bolivar? No, was interested but ended up working on other things.
Drivers: I2S: Andrzej? Carles has discussed it with them. TSC has no objections. Armando Visconti, avisconti, has been maintaining I2S microphone drivers.
Drivers: Interrupt Controllers: Any ideas? One of the Andrews? Stephanos, non cortex-m ARM work.
Drivers: LED: @Mani-Sadhasivam as maintainer? Need to add them to pending PRs. No objections.
Drivers: LED Strip: Marti is accurate.
Drivers: Lora: Marti? @Mani-Sadhasivam as maintainer? Andreas Sandberg has been working on it. Check with Mani about time availability and TSC ok with them.
Drivers: Neural networking: Someone from Intel.
Drivers: PCI: Add someone from Broadcom? Up to the maintainer.
Drivers: PTP clock: jukkar? Confirm with them.
Drivers: PWM: Andrzej? Confirm with them and TSC has no objections.
Drivers: Video: loicpoulain: Confirm with them and TSC has no objections.
Drivers: Watchdog: Any suggestions? Propose a new maintainer who has been working in that space.
Filesystems: Lots of collaborators but no maintainer. Generally too broad of a category. [Kumar] Dominic? [Anas] Split FS so the existing entry is *just* the subsystem, not the implementations. That way we can have maintainers for each implementation.
JSON Web Token: [Carles] Have had recent contributions from Marcus Fuks (?) [Anas] Asking could be a deterrent to further contributions. [David Leach] Add the person as a collaborator. Should JWT be a subsystem or a lib? [David Brown] It’s there for linker reasons. Maybe David should be the maintainer?
Kconfig: ulfalizer no longer maintaining. [Anas] Wants to improve the Kconfig script. Switch Orphaned and needs further discussion.
MCU Manager: [Carles] Probably just forking this because upstream isn’t active. Dominic Arma? Check with them and no objections from TSC. Kevin Townsend also interested, Runtime isn’t. Don’t want iOS and Android parts in Zephyr.
NIOS-2 arch: Should be nashif? Yes. Not Ruud.
Power management: Check with wentongwu. No objections from TSC.
RISCV arch: Not really maintained, nategraff-sifive isn’t active. No objections to making it orphaned.
Shell: Jakub-uC can be readded because they are back to nordic.
Storage: [Carles] Is actually only SDCard? No flash map and… Andrzej P? No objections, check with them.
Tracing: Is maintained.
USB: finikorg? [Anas] Are they actually active still? Need to confirm with them. [Anas] Suggest orphan and check with them. That way we can start fresh. No TSC objections.
X86 arch: Switch to flavio. [Anas] No need to check with andreboie. Intel has already switched ownership internally.
[Kumar] Let’s make sure we aren’t missing subsystems.
[Anas] Push to merging soon and follow up.
Ok, to merge soon and then iterate because this is a new system.
One or two weeks to hear back from folks. If they don’t get back to us then we should leave as orphaned and modify later once we hear back.
Shoot for next Wednesday’s TSC meeting for final approval.
Developer Workflow, Slack [Kumar]
PRs from new contributors frequently fail remote git lint checks.
Thoughts on pre-commit hooks? Trade-off is needing more tools locally.
Document how Bluetooth and TCP/IP stack calls in Zephyr are different than Linux or Windows:
Introduction to new tools like West. Be clear about optional versus required use:
More information about West and how it uses Kconfig, DTS, Cmake:
Create architecture diagrams to help with some of the topics above:
Update error messages to be very specific to the error experienced to enable root cause identification:
Adding tools to help with multi-thread application development and de-bug:
Comprehensive sample app and tutorial.
Wrap Up [All]
[Maureen] Prioritize what things we want to focus on
Process discussion - good way forward on that
Maureen - actions to incorporate feedback from Strategic Objectives
Path forward for Discord?
[Kumar] Email to dev list (include history, benefits of each, poll that provides 2 options) OR specify history is important; TSC has made the decision to transition to a different solution; TSC votes to finalize.
Decision: Announce over mail list as FYI (1 week of comments) + Schedule as topic in next TSC meeting to review any additional feedback and TSC Vote on to finalize
[Ioannis] TSC schedule w.r.t. Holidays?
TSC members requested to add their known vacations to TSC working doc and/or notify Maureen