Re: [riot-devel] FOSDEM 2020 RIOT BoF summary
chrysn wrote:
>> Any details who (or how many) attended the meeting?
> About 12 people altogether; I didn't take note of names.
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?")
signature.asc
Description: PGP signature
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] FOSDEM 2020 RIOT BoF summary
On Sun, Feb 02, 2020 at 10:16:45PM +0100, Matthias Waehlisch wrote: > Any details who (or how many) attended the meeting? About 12 people altogether; I didn't take note of names. KR chrysn signature.asc Description: PGP signature ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] FOSDEM 2020 RIOT BoF summary
Hi Christian,
many thanks for the minutes!
Any details who (or how many) attended the meeting?
Thanks
matthias
On Sun, 2 Feb 2020, chrysn wrote:
> Hi,
>
> On Fri, Jan 31, 2020 at 03:55:08PM +0100, Koen Zandberg wrote:
> > 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
>
>
--
Matthias Waehlisch
. Freie Universitaet Berlin, Computer Science
.. http://www.cs.fu-berlin.de/~waehl___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] FOSDEM 2020 RIOT BoF summary
Hi,
On Fri, Jan 31, 2020 at 03:55:08PM +0100, Koen Zandberg wrote:
> 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
--
I shouldn't have written all those tank programs.
-- Kevin Flynn
signature.asc
Description: PGP signature
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel
