OlegH
    • Create new note
    • Create a note from template
      • Sharing URL Link copied
      • /edit
      • View mode
        • Edit mode
        • View mode
        • Book mode
        • Slide mode
        Edit mode View mode Book mode Slide mode
      • Customize slides
      • Note Permission
      • Read
        • Only me
        • Signed-in users
        • Everyone
        Only me Signed-in users Everyone
      • Write
        • Only me
        • Signed-in users
        • Everyone
        Only me Signed-in users Everyone
      • Engagement control Commenting, Suggest edit
      • Invitee
      • No invitee
    • Publish Note

      Publish Note

      Everyone on the web can find and read all notes of this public team.
      Once published, notes can be searched and viewed by anyone online.
      See published notes
      Please check the box to agree to the Community Guidelines.
    • Commenting
      Permission
      Disabled Forbidden Owners Signed-in users Everyone
    • Enable
    • Permission
      • Forbidden
      • Owners
      • Signed-in users
      • Everyone
    • Suggest edit
      Permission
      Disabled Forbidden Owners Signed-in users Everyone
    • Enable
    • Permission
      • Forbidden
      • Owners
      • Signed-in users
    • Versions and GitHub Sync
    • Note settings
    • Engagement control
    • Transfer ownership
    • Delete this note
    • Save as template
    • Insert from template
    • Import from
      • Dropbox
      • Google Drive
      • Gist
      • Clipboard
    • Export to
      • Dropbox
      • Google Drive
      • Gist
    • Download
      • Markdown
      • HTML
      • Raw HTML
Menu Note settings Sharing URL Create Help
Create Create new note Create a note from template
Menu
Options
Versions and GitHub Sync Engagement control Transfer ownership Delete this note
Import from
Dropbox Google Drive Gist Clipboard
Export to
Dropbox Google Drive Gist
Download
Markdown HTML Raw HTML
Back
Sharing URL Link copied
/edit
View mode
  • Edit mode
  • View mode
  • Book mode
  • Slide mode
Edit mode View mode Book mode Slide mode
Customize slides
Note Permission
Read
Only me
  • Only me
  • Signed-in users
  • Everyone
Only me Signed-in users Everyone
Write
Only me
  • Only me
  • Signed-in users
  • Everyone
Only me Signed-in users Everyone
Engagement control Commenting, Suggest edit
Invitee
No invitee
Publish Note

Publish Note

Everyone on the web can find and read all notes of this public team.
Once published, notes can be searched and viewed by anyone online.
See published notes
Please check the box to agree to the Community Guidelines.
Engagement control
Commenting
Permission
Disabled Forbidden Owners Signed-in users Everyone
Enable
Permission
  • Forbidden
  • Owners
  • Signed-in users
  • Everyone
Suggest edit
Permission
Disabled Forbidden Owners Signed-in users Everyone
Enable
Permission
  • Forbidden
  • Owners
  • Signed-in users
Import from Dropbox Google Drive Gist Clipboard
   owned this note    owned this note      
Published Linked with GitHub
Subscribed
  • Any changes
    Be notified of any changes
  • Mention me
    Be notified of mention me
  • Unsubscribe
Subscribe
# RIOT Open Assembly @ Summit 2021 Attendees --------- - Martine - maribu - aabadie - dylad - Frank - javier - saniea - Wojtek - Oleg - Cedric - Koen - Kaspar - Leandro - Jürgen - Karl - Michael (MCR) Richardson - Joakim - José - Kevin - Kirk - benpicco - Cenk - Philipp - Christian - Peter - Hauke - Ioannis Chatzigiannakis - Jelle - Emmanuel - Daniel Lockau - Andrey Kolesnikov - Jean Dudey - Fabre - Gilles - Smit Shah - Yiannis Christou - Hendrik - Nils Ollrogge - Olaf Bergmann - Akshai - Matthew Bradbury Notes ----- - Moderator: Oleg - Note-taking: Christian, Martine & Kaspar Agenda ------ - Agenda bashing - Dropping hardware support - Releases: Changing the default round-robin - RIOT road map - Subsystem maintainers - open discussion Dropping hardware support ------------------------- - Oleg: - no clear path for removing h/w support - supporting unused hardware may slow us down - is there a semi-automatic way for that? - Last VMA Oleg proposed annonimized usage information - Sees the problematics there - Kaspar: - If people are annoyed, ask around if it is used, if nobody screams: Drop it (the current approach) - Effectively decide by maintainance burden - Oleg: - CPU / Board removal need to be distinguished - Kirk: do 8bit/16bit/PIC special cases cause complexity? - Kevin: do we keep platforms, where design is flawed from the beginning? (?) - Marian: THere is value to having at least 8-bit and one 16-bit platform - Oleg: Value only if these kind of platforms are in use. Is this the case? - Karl: If we care about 8- and 16-bit now, we might have an advantage when 64-bit support is necessary - Marian: - from technical side: Lower bit platforms can actually have lower power consumption + AVR is better shielded for radiation (cube sats) - Old intel 8-bit is still surprisingly popular. Maybe add that rather than AVR - Main point for AVR: Every student has some Arduino flying around => first RIOT platform - Hauke: - What can be made more efficient when dropping boards? - Maintainance, but what else? - AVR still well maintained 1. Easy entry point 2. Cross-checking 3. Market (?) - As long as there is maintainance there is no reason to drop it - Marian: There was just a new AVR-platform added, so there seems to be still maintainance interest - Michael: Does RIOT still fit AVR? - Kaspar: If not, its a sign of bloat - Michael: Ok, but there might be things we want to add that do not fit AVR - Kaspar: No compromises for AVR, what doesn't fit doesn't fit. - karl: Could check for whether there are any ifdefs for these to quantify maintenance burden. - Marian: additional use for AVR: it's easier to judge performance impact there. On ARM there's luck involved when data is added due to cache hits and misses. - benpicco: MIPS (martine: and MSP430) are on the slate, nobody is seriously considering dropping AVR. - Marian: but MIPS is 32-bit so do we gain anything from keeping support? - Kaspar: All those toolchain special cases!!1! Marian: Let's call it a gain ;-) - Oleg: Time span? benpicco: Standard deprecation cycle for two releases. Marian: Can mark MIPS module as deprecated, and people see it through build system because they use deprecated modules. - Oleg: Sounds like a clear plan. - Build time? Kaspar: Not building deprecated stuff would worsen code rot. - Martine: When removing the MSP-430 platforms currently on slate for removal, is there still a MSP-430 platform? There was a newer TI platform using MSP430 discussed to be ported *crickets* - Oleg: Build times ... is this an issue of not having enough hardware? Kaspar: Would get better with more hardware. Marian: Have a server that just needs to be installed. Kaspar: Builds need 1h now, had to wait 5h during sprint day. But that's different subject. Kevin: How much would it cost to just rent resources? Maybe it's just a few Euro. - benpicco: For quick CI builds, just a curated list of selected boards? Maribu: Also wonder about the 50 flavors of the same board, with different button and LED configurations. Martine: We did this with LLVM builds, had a selection of boards for each CPU type. Hauke: Could we do like blacklisting, "blacklisted because too similar for X" and then build in nightly only? Should be easy to implement. Can then strip down many boards. - karl: "skip compile" tests are a thing. Can we do this specifically for an architecture? Maribu: same with new peripherals -- would just like to do explorative builds on everything that's using that platform. Martine: Some people provide paperCI. But doc of access to those is an issue. Kevin: I could offer access for people who want to the one at HAW. - Alex: Have some work in the pipe regarding front-end and back-end changes (interaction with github). Able to say what to trigger, but in the end will still go into the same work queue. - Kevin: Are we going off track? Alex: was about testing specific set of boards - Kevin: Let's go back to discussing dropping hardware support - Kevin: MIPS as a first step, MSP-430 not yet, because a bit controversial - Oleg: could the blacklisting strategy work for stm32 variants? - Alex: not trivial, there are many variants . ESPs are a bit annoying because they subtly change Ethernet wiring. Would be great to have more if that doesn't affect the CI time. - Kaspar: \[?\] We have lots of configuration and can't distinguish between code and configuration. - Kaspar: Had this makefile-based, but with ccache it turned out to be faster to rebuild all. - Oleg: So to summarize, can get rid of some CI time from new ESP boards, but not for Nucleo - Alex: Nucleo is nice because cheap and many variants work, but a pain to maintain because of those variants - Oleg: Concluding. Discussion on CI and autospeedup can be continued at end of assembly if time available. Releases: Changing the default round-robin ------------------------- - Martine: Background: Normal way to find release manager is to have volunteer in best case (might be passive volunteering); lacking one, the founding organizations go round robin and pick an employee. Right now at FU it's me and Hauke, with the latter declining, so it's always me. So maybe change and update to more community based approach: For whom was it the longest to RM, or who has never? (LRU maintainers) - Oleg: Time estimates for RM'ing? Martine: Not as time consuming as it used to be, but still some work. Brought this up for 2022.01, can still do that but every 3 releases is not scalable even with all automation. - Kaspar: Also takes time to read up and get familiar again, takes research time; 2 weeks? - Oleg: 2 weeks is a lot of time for everyone not getting paid. - Kaspar: We'd still accept "sorry can't do". Maybe pool of maintainers who can do, and round-robin there? - MCR: Apprentice program for RMs? - Kaspar: Yes, and/or co-RM who can ACK your stuff. Next time I'd pick a RM buddy right away. - Benpicco: Maybe ask previous RM? Martine: Sometimes done like that, but sometimes not available any more. - Oleg: Pool is good. Benpicco: Should be opt-out. Martine: Need to organize that pool in a document, or just track opt-outs? Oleg: Do we even have a list of all maintainers? Martine: [Maintainer group in forum](https://forum.riot-os.org/g/Maintainers). Oleg: Lists can get out-of-sync. Martine: Opt-out list is less likely to. - Oleg: Maintainer list growing outdated. Martine: There was an idea of having a maintainer ping on summits. - Oleg: So, opt-out list? Kaspar: Makes sense, drop institutions for Martine's sake. Martine: And for Kaspar when Schleiser Inc. comes back ;-P - Opt-Out list was created as a [Wiki post on the forum](https://forum.riot-os.org/t/release-management-opt-out/3354) RIOT road map ------------------------- - Oleg: Who is aware of [road map](https://github.com/RIOT-OS/RIOT/wiki/Roadmap) existence? (Some unaware, others forgot) - Emmanuel: Idea was to have collaborative updates; what happened was attempts to delegate maintenance and that didn't work. Tied to topic of more offical steering people for subsystems (who'd track and update roadmap). Map is important to have and maintain, maybe takeaway is that [?] that needs better organization. - Jose: There's some in the forum, with dedicated entries. Maybe use that, and establish how to maintain. - Kaspar: Endeavors category opened for that. - Oleg: Important to have roadmap -- for us as community (people get too deep into one issue), and to outsiders (esp. coming from industry, to see what is unsupported and what's close on roadmap). - Alex: [?] - Benpicco: Industry can implement and contribute. - Alex: With the list we can identify people that work on them. As insiders we know that, from the outside it's not clear, and then several people start on WolfSSL. - Benpicco: But that's more in the direction of having subsystem maintainers. - \[ MCR on chat \] Celebrate what has been already crossed out (with many +1s on chat) - Karl: maintainer-to-subsystem matrix? - Emmanuel: Prototype roadmap tried to do that. - Leandro: ... code owners? - Oleg: Subsystems and roadmap are obviously closely related -- but anyhow would like to discuss future of roadmap first. Important to have it visible, also from web (but needs better shape). HBO adding to default VMA agenda a roadmap step? Need initial showable version, but then can table that on every VMA / release. Alex: +1. - Kaspar: But need to discuss what's to be there. - Benpicco: Focused to subsystems. 802.15.4 stack, CoAP stack, etc. - Kaspar: But need to agree on what to put there. Maybe there's even different opinions on where to go there. - Oleg: Roadmap task force for initial text for next VMA? Kaspar: Discussed much in last VMA, and breakout session already planned. - Alex: Make sense to have wishlist, putting things to roadmap in time? - Leandro: Feature request issues? Emmanuel: Central place. [...] - Emmanuel: When there's lead-up time (Kconfig decision to implementation), the roadmap entry is handle for that. On VMA, can be time consuming, will need moderation. - Oleg: Survey current colleagues on what they expect of IoT OS. - Kaspar: Right now different people would write up different things there. Alex: But there'd be overlap. - Oleg: Maybe two different versions, one short/high-level for website, and details. - Kaspar: [...] voting in forum for who'd like to see which feature. - Karl: Didn't know about roadmap page. - ... next steps / task force? Oleg: Breakout session tomorrow. - Oleg: What's process for breakout session scheduling? Martine: Planned in evening, but not all maintainers can't be in a single session. - Martine: Breakout attendance maybe problematic due to maintainers also having other breakouts in parallel - Kaspar: Talked a lot with Francisco, so moved to breakout session there -- but if there's not enough attendance ... but maybe subgroup can make proposals and then bring them to all. - Oleg: there will likely be more discussions on this to come, but having a (mini) breakout to spark discussion is good! Subsystem Maintainers --------------------- - Benpicco: Subsystem roadmaps can only be written by those on the subsystem. Roadmap can't be imposed from outside - Emmanuel: So start with a list of subsystems? - Kaspar: The only thing having a subsystem maintainer does is that people come to you for help. Oleg: Does that work? Martine: I get some, and at least can redirect them. Kaspar: Reviews do get assigned. - Oleg: Maybe add to PR procedure to get subsystem maintainer ACK? Doesn't need detail review, just for "does it make sense?". [?]: Would make a lot of sense. Oleg: So then (re)identify subsystems and assign people. - Emmanuel: Have Github labels on areas. Martine: Can be used as template for list of subsystems. Emmanuel: Maybe some areas in same subsystem, but at least used successfully to group PRs so far. More solid base than structure in current roadmap. Kaspar: Tooling would be great, so that github pings subsystem people when subsys is assigned. [?]: Codeowners? Kaspar: Doesn't always map to code. Martine: Triage bot could ping based on subsystem / maintainer matrix? Or is the bot too restricted? Alex: Think could be hacked, but needs work, basically "write your own tool" is as complex - Karl: How managed ACK-counting-wise? Maribu: Subsystem maintainer review can be fast, often based on title and PR description alone. - Koen: happens naturally now, it'd just be more official. Kaspar: But if you don't watch closely things can slip through. Formalizing subsystems would help b/c someone has vision and can direct. - Oleg: Sequence things to not waste reviews on things rejected on conceptual level? How do we get good responsivity? - Kaspar: Even if it gets a bit slower, it'd be an improvement unless we're driving-people-away unresponsive. ?: A flag, not an ACK. Oleg: Or a NACK. Maribu: Implicit ACK if no NACK? Kaspar: No, rather escalate. Maribu: Myself, I react (based on [codeowners](https://github.com/RIOT-OS/RIOT/blob/master/CODEOWNERS)) on things that disturb me. - Kaspar: A flag that has to be set to be merged would be easy to implement. - Benpicco: Is it a problem that controversial stuff gets merged too soon? - Kaspar: Makes stalls more explicit, and makes better procedure for decisions. - Alex: How to promote sub-system maintainers? How to coordinate between subsystems? - Kaspar: VMA could promote them? Coordination could happen naturally. Let's go the first step and let's figure the details out by doing - Oleg: Yes let's give it a try. Worried about responsiveness issue - Oleg: Another problem: People might think of them as sub-system maintainers, but are not seen as such by others. Maybe making it official might help. - Oleg: Postpone final decision to breakout session. Open Discussion --------------- * Kirk: [OpenCollective](https://opencollective.com/) * Would need 2-3 approvers e.g. on forum. Much easier than university finance systems. Take small fees but way less than university overheads. * Kaspar: Started years ago but got nowhere, maybe start over after people turnover. (NVM, different stuff) * Oleg: AOB? No

Import from clipboard

Advanced permission required

Your current role can only read. Ask the system administrator to acquire write and comment permission.

This team is disabled

Sorry, this team is disabled. You can't edit this note.

This note is locked

Sorry, only owner can edit this note.

Reach the limit

Sorry, you've reached the max length this note can be.
Please reduce the content or divide it to more notes, thank you!

Import from Gist

Import from Snippet

or

Export to Snippet

Are you sure?

Do you really want to delete this note?
All users will lose their connection.

Create a note from template

Create a note from template

Oops...
This template is not available.
Upgrade
All
  • All
  • Team
No template found.

Create custom template

Upgrade

Delete template

Do you really want to delete this template?
Turn this template into a regular note and keep its content, versions, and comments.

This page need refresh

You have an incompatible client version.
Refresh to update.
New version available!
See releases notes here
Refresh to enjoy new features.
Your user state has changed.
Refresh to load new user state.

Sign in

Forgot password

or

By clicking below, you agree to our terms of service.

Sign in via Facebook Sign in via Twitter Sign in via GitHub Sign in via Dropbox Sign in with Wallet
Wallet ( )
Connect another wallet

New to HackMD? Sign up

Help

  • English
  • 中文
  • Français
  • Deutsch
  • 日本語
  • Español
  • Català
  • Ελληνικά
  • Português
  • italiano
  • Türkçe
  • Русский
  • Nederlands
  • hrvatski jezik
  • język polski
  • Українська
  • हिन्दी
  • svenska
  • Esperanto
  • dansk

Documents

Tutorials

Book Mode Tutorial

Slide Mode Tutorial

Contacts

Facebook

Twitter

Discord

Feedback

Send us email

Resources

Releases

Pricing

Blog

Policy

Terms

Privacy

Cheatsheet

Syntax Example Reference
# Header Header 基本排版
- Unordered List
  • Unordered List
1. Ordered List
  1. Ordered List
- [ ] Todo List
  • Todo List
> Blockquote
Blockquote
**Bold font** Bold font
*Italics font* Italics font
~~Strikethrough~~ Strikethrough
19^th^ 19th
H~2~O H2O
++Inserted text++ Inserted text
==Marked text== Marked text
[link text](https:// "title") Link
![image alt](https:// "title") Image
`Code` Code 在筆記中貼入程式碼
```javascript
var i = 0;
```
var i = 0;
:smile: :smile: Emoji list
{%youtube youtube_id %} Externals
$L^aT_eX$ LaTeX
:::info
This is a alert area.
:::

This is a alert area.

Versions and GitHub Sync
Upgrade to Prime Plan

  • Edit version name
  • Delete

revision author avatar     named on  

More Less

No updates to save
Compare with
    Choose a version
    No search result
    Version not found
Sign in to link this note to GitHub
Learn more
This note is not linked with GitHub
 

Feedback

Submission failed, please try again

Thanks for your support.

On a scale of 0-10, how likely is it that you would recommend HackMD to your friends, family or business associates?

Please give us some advice and help us improve HackMD.

 

Thanks for your feedback

Remove version name

Do you want to remove this version name and description?

Transfer ownership

Transfer to
    Warning: is a public team. If you transfer note to this team, everyone on the web can find and read this note.

      Link with GitHub

      Please authorize HackMD on GitHub
      • Please sign in to GitHub and install the HackMD app on your GitHub repo.
      • HackMD links with GitHub through a GitHub App. You can choose which repo to install our App.
      Learn more  Sign in to GitHub

      Push the note to GitHub Push to GitHub Pull a file from GitHub

        Authorize again
       

      Choose which file to push to

      Select repo
      Refresh Authorize more repos
      Select branch
      Select file
      Select branch
      Choose version(s) to push
      • Save a new version and push
      • Choose from existing versions
      Include title and tags
      Available push count

      Upgrade

      Pull from GitHub

       
      File from GitHub
      File from HackMD

      GitHub Link Settings

      File linked

      Linked by
      File path
      Last synced branch
      Available push count

      Upgrade

      Danger Zone

      Unlink
      You will no longer receive notification when GitHub file changes after unlink.

      Syncing

      Push failed

      Push successfully