FOSDEM 2020 RIOT BoF

Hi all,

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.

Cheers Koen

Hi Koen,

I'll be there on Saturday from 10am and leaving around 18pm. I have no time-slot preference. See you tomorrow! Cheers,

Francisco

----- Mail original -----

Hi again,

We got ourselves a slot at 16:00 today in room H3242, just follow the BoF signs in building H!

See you there!

Koen

Hi,

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.

KR chrysn

Hi Christian,

  many thanks for the minutes!

  Any details who (or how many) attended the meeting?    Thanks   matthias

About 12 people altogether; I didn't take note of names.

KR chrysn

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?

("Any fresh meat?")