[riot-devel] Easing maintainer burden

Koen Zandberg koen at bergzand.net
Tue Feb 6 15:42:56 CET 2018

Hi all,

At FOSDEM I attended a talk about how Easybuild simplified their
contribution process[1] (recording and slides available). The short
story is that they have added functionality to their tooling to
integrate with Github to simplify some of the repetitive tasks for
contributors and maintainers. I think some of their ideas can be adapted
to RIOT, mostly the points about easing maintainer burden.

1. Have Murdock comment on PR's on (some) build failures. The goal here
is to give the contributor a nudge that the build failed. Currently an
inexperienced contributor might miss the small red cross indicating
build failure. Having Murdock comment on the PR about the build failure
and maybe even with a short explanation why the build probably failed
could increase contributor responsiveness while removing the need to
have maintainers poke the contributor and having to explain why the
build failed.

2. Automated test uploading and reporting. The idea here is to have a
script that executes a test and uploads the result to a gist and attach
it with a comment to a PR/issue. This would ease test failure/success
reporting. This way we can provide a default template to provide all
relevant information (toolchain versions, build log, test output etc.).
For a contributor it should be easier to report test failure for issues,
while for maintainers it becomes easier to report test success/failures
to reviewed PRs.

3. Documentation about the directory tree. This is about having
documentation about what can be found where in the directory structure.
Mostly to prevent new contributors from having to search around in the
directory tree. Most parts of the directory tree is quite obvious, but I
think it can help the inexperienced developer to have some guide for
this. Not sure whether this already exists though.

4. Skeleton drivers: In my opinion it should be as easy as possible to
add simple sensor drivers to RIOT. If a template-like skeleton dummy
driver is added which can simply be copied and filled in for a new
sensor, the contribution threshold could be lowered. Mind that this is
aimed at the simple I2C/SPI drivers which can be implemented with not
much more than init and get functions (something like the jc42 sensor

A lot more menial tasks of reviewing can be reduced of course, for
example, a scripts to check out a PR in a different directory, and as
Kaspar already proposed, a script to create backport PRs[2].

What I would propose is having some script, a riot.{sh,py} to handle the
maintainer automation together with point number 2. Point 4 could
relative simple be added as a driver with tests. Number 1 probably
requires Murdock to be extended, but could be valuable to have. Number 3
would have to be added to the Doxygen together with a link in the readme.


[1]: https://fosdem.org/2018/schedule/event/contributor_automation/
[2]: https://github.com/RIOT-OS/RIOT/issues/8523

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.riot-os.org/pipermail/devel/attachments/20180206/de209329/attachment.sig>

More information about the devel mailing list