For those of us attending FOSDEM this year, I plan to grab a BoF room
time slot to have a small RIOT meet-up. Unfortunately from what I've
heard there won't be a RIOT stand this year again, but we can meet-up
anyway of course. Please let me know if you have any preference for a
time slot.
I'll announce here and on IRC as soon as I have a time and a room
reserved for us.
For those of us attending FOSDEM this year, I plan to grab a BoF room
time slot to have a small RIOT meet-up.
I've taken some notes on this:
After we've finished admiring his PineTime, discussion started about fields
which we could improve in RIOT, with a focus on the input RIOT users and
newcomers. (Please apologize my sketchy notes)
* Documentation
* Document modules (and make them discoverable)
* Document how to use in them, in addition to what-are-its internals
* Is Doxygen sufficient for this purpose? There was a PR to Sphinx
some time ago, but would such a migration even feasible?
* Grouping of drivers and/or examples in documentation and paths
* "When developing an X, how do I..." for X in application, driver
etc.
* Module dependencies, esp. how they are done, and pseudomoldules (and
which are there?)
* Gaëtan wrote basic doc on what a module is ... where is it? is it
sufficient?
* How are networks configured?
* Many of those are currently solved by people coming to IRC / Matrix
* Document environment variables inside the makefile. BOARDSDIR?
EXTERNAL_MODULES_DIR? Make them searchable.
* PR experience: PR workflow is insufficiently described in
CONTRIBUTING, some relevant information is in the maintainer
documentation ("Why doesn't murdock build?")
* PRs not being responded to. Use GitHub code owners file (even though
we call it something else, but that's their file name)?
* Preselection of PRs? Making someone feel responsible for code?
* Run CI for PRs if nothing else running?
* security implications
* "When I got an ACK, why isn't it merged immediately?" Maybe have
murdock reply to PRs on what is required?
* uncrustify -- What do I need to address, what is a suggestion, what
will maintainers enforce?
* When is a "*ping*" OK, is it encouraged, etc.? Ping whom?
* More often, for annoying little stuff, push to contributor branch
(if allowed by contributer)?
* How do people who did some comments stay in the reviewers list? Whom
to add, what happens if nobody is assigned after triage when someone
removed themselves?
* The dependency graph is not accessible: There can't be a `make
info-module-tree`.
* When will we run into make limitations? Won't need to replace make
for everything, just for determining USE_MODULES.
* Defaults for pseudomodules, and optional orders of preferences?
stdio_cdc_acm vs stdio_uart etc
This certainly doesn't cover all topics touched, and might even have
missed proposed solutions, but might help spark further discussion
and/or identify points where improvement would be quite welcome.
I didn't go/make it, because I was too far away when the time/place got set.
The more interesting question is perhaps: of the 12, were they are familiar
faces, or were there people who knew nothing?