VMA 2020 02 minutes
Michel Peter Cenk Oleg Koen Francisco Robert José Ken Kaspar Alexandre Martine Emmanuel Benjamin Dylan
- Debrief 2020.01 release (Francisco)
- A quick word from 2020.04 release manager (José on behalf of Leandro)
- Determining the Release Manager 2020.07 (Oleg)
- Organization and moderation of the next VMA (Oleg)
- Kconfig (José)
- RIOT Sprint Day (Kaspar)
- Tutorials for RIOT: How to get started & How to send low-level packets (the correct way) (Robert)
- Deprecation (Francisco, proxying for Marian)
- Merging/using support for PROGMEM (Kaspar on behalf of Maribu)
- Upcoming MooC based on RIOT and IoT-Lab (Alex & Emmanuel)
- Open mic / reflection of this meeting
The original agenda/topic collecting pad is here
https://github.com/RIOT-OS/RIOT/wiki/Debrief-for-2020.01 added new automated tests (e.g. xtimer). Started testing with these added automated tests even before the feature freeze! Helped a lot. Release teting got easier.
- Martine: there is a PR to have a generic interface for shell commands -> better automation For the parts where there was well-known "code owner" things were easier -> code-owners info = GOOD. More code-owner info = BETTER Allowing the release manager to reschedule CI builds would speed up the process a lot.
- Alex: what do you think about release notes process?
- Francisco: Took around 1 day. Good labels help a lot!
two main goals for next release
- More support for Kconfig
- use riotnode more for an improved testing
- Martine as a fallback option?
- No other volunteers: Martine will take over that release
- Oleg: Lets re-evaluate need for period after that meeting
- If nothing changes we keep cycle -Asuming the above, next meeting would be first half of May
- Kaspar volunteers to steer the next VMA
-
TODO: add link to kconfig slides here! https://drive.google.com/file/d/1BBiC3PqOYaxbJjP7VB3VrGjFIazOu9NX/view?usp=sharing
-
Q: Granularity of symbols / modules / ...? (Robert)
-
A: As much as we want (we can map all modules to one or more symbols). We have full control of that
from the chat: Robert: but numbers are compile time, not configuration time, right? Martine: Configuration + compile time, I think Robert: we don't know what the actual overhead from kconfig is, if we'd remove other clutter that is not required anymore Robert: but what if hardware crc or csma differs on the boards? José: regarding that, if there's hw crc (in all radios) we don't need to have code that checks "if the radio supports crc"
if there are radios that support it, and some others that don't, we need to compile a "radio caps" logic (hey, does this radio provide HW CRC?)
if we know no radio supports CRC, we always have to callculate it
does this solve the original question?
Robert: I think so, probably was a bad example :D
I think the RNG was a good example already.
José: ok, good to know :)
Robert: I was in general thinking about applications, where some parts are not available on others, or maybe a different type of temperature sensor. E.g. KConfig should select a temperature sensor
-
Kaspar: 2sec building hello-world is very much, even without kconf, performance is a (continuing) concern -> keep CFLAGS as a first source of configurations
-
got dropped: build system is slow, kconfig dictates build system aspects. better not tie to slow build system -> better not drop build system independence of code.
-
Oleg: we should distinguish between performance for configuration and for building an application
-
Martine: During measurements was CFLAGS configuration on for Kconfig measurements? Jose: Yes, that's why it is not a fair comparison.
-
Alex: Regarding dependency resolution it is promising to improve things. But, it imposes "major changes" to application developers that are used to USEMODULE+=...
-
Jose: See FAQ on slides
-
Kaspar: How to configure which board you build for?
-
Jose: we have control but we do it similar to current approach
-
Kaspar: How to build the same configuration for two different boards?
-
Jose: You can expose application specific configuration files
-
Francisco: We already have applications that include platform specific Makefile.dep files. How would we handle that?
-
Jose: kconf can merge configurations from multiple merge config files.
-
Alex: Can we use some overlay concept here?
-
José: might be possible
-
Francisco: can you use device tree without kconfig?
-
José: would be possible, but it's very convenient to use with kconfig
-
Francisco: Are there current build system issues that need fixe before go over to next phace
-
José: Basically not but we need to find all dependencies
Out of time, discussion needs to be continued on the list
- Some had their first sprint day yesterday -> great success
- Peek into Github project https://github.com/RIOT-OS/RIOT/projects/26
- Kaspar invites everyone to join next time: Tuesday 25.02
- Ideally there will be a weekly schedule
- Martine: Use the Github project feature for the monthly H&A ?
- Peter: how is it organize? who's responsible
- Kaspar: just started, but the idea would be to have a (monthly) rotation of steering persons have a telco at the beginning of the day (input: a couple of PRs proposed by each participant) Then during the day sprint review / mods in close contact (e.g. IRC...) and perhaps merge ;)
- Oleg: should we announce it on the devel mailing list as well?
- Kaspar: let's first gather more experience and keep it maintainer only for starters
- Alex: Maybe this approach doesn't scale well. Mabye we organize in groups or task forces?
- https://trac.ibr.cs.tu-bs.de/project-cm-2012-inga/wiki/RIOT#SendingIEEE802.15.4Framesacrossnodes
- Initial problem: no way to send low-level packet without looking deep into network stack implementations
- a lot of code is required to send low-level packet
- Robert asks for help or hints how to do easier? How about an example?
- Martine: For high layer communication there is sock
- Martine: For low-level there is gnrc_netif which is actually a bit complicated. We have José working on that
- José: Idea is to add new entry points (e.g. netif_send)
- Robert: We should discuss this "offline" or better: within the task force. Lets announce on mailing list.
- In general: wish for API on every layer
- Martine: It won't be as easy as contiki because they only have few and simple stack models
- Issue popped up in some lpcxxx CPU PR
- When should we start removing a feature?
- Deprecation removal process required
- Robert agrees. Benjamin too.
- No objections!
(for Harvard architecture)
- Kaspar: would improve support for AVR, but introduce overhead vor von Neumann architectures
- Kaspar: we should avoid extra maintenance effort for the rest
- Kaspar: if changes can be contained inside AVR specific code, that would okay -Oleg summarizes: Changes would be considered "ok" if only affect Havard architecture and no others
from the chat: Robert: I think regarding about marian's topic, there is some code-wise overhead. Maybe we just have to implemented and evaluate?
Not released yet, coming up in March. Should be useful for beginners, can register already here: https://www.fun-mooc.fr/courses/course-v1:inria+41020+session01/about Emmanuel: will need beta testers soon ;) Stay tuned!
-
Many attendees agree that it makes sense to discuss in VMA instead of mailing list
-
People are happy with (technical) conferencing quality
-
Emmanuel: should we keep the periodicity for the VMA -> participants agree
-
Robert: How do new-comers start with RIOT?
-
Francisco: There are two different tutorials
-
Martine: Tutorials are a bit outdated we should update
-
Robert: Merging both online courses would be cool
-
Koen: People on FOSDEM asked for usage example per module???
-
Good example http://doc.riot-os.org/group__sys__event.html
-
Robert: Maybe even put more README.md files into github? Those could explain the directory structure
- Bad example: https://github.com/RIOT-OS/RIOT/tree/master/sys/net
-
Alex: No clear distinction between tests and examples
-
Some people agree that a hierarchy in tests, examples, drivers? might make sense
-
maybe move tests directory into directory of the individual modules? -> Maybe topic for next VMA agenda? +1
-
Koen proposes to document directoy structure in directory structure
-
Koen: From FOSDEM: search function of doxygen is hard to use