[riot-devel] Minutes from face-to-face meeting @ FU Berlin on August 29, 2013

Oleg Hahm oliver.hahm at inria.fr
Thu Sep 12 16:50:46 CEST 2013


Dear RIOT developers,

I've just realized that I haven't sent the minutes from the last meeting to
the list so far. Sorry for the delay:


Minutes from the Face-to-Face developer meeting @ FU Berlin on August 29, 2013
==============================================================================

Participants: Oleg Hahm, Christian Mehlis, Ludwig Ortmann, Emmanuel Baccelli,
              Kaspar Schleiser, Thomas Eichinger, Martin Lenders
Minute taker: Kaspar
 
1. Branching
============
The question was raised if the master branch should be continued as the main
development branch or - as originally intended - contain always a stable
version of RIOT without any API changes.

In order to keep it simple, it was decided to use the master branch as the
main development branch and create branches for the releases.

2. Fix-up releases
==================
The branch for a release will introduce a feature freeze in this branch. After
a testing period the HEAD of this branch will be tagged as the release. Fixing
commits can still go into this branch and might get tagged as a fix-up
release. Further feature development continues in the master branch as usual.

3. Merging repositories
========================
There was a consensus on merging all three existing repositories (RIOT,
boards, and projects) into one RIOT repository. The content of the current
projects repository will be split up into two folders: examples/ and tests/.

Additionally, there's going to be a repository for applications, containing
bigger demo applications. This might also help to ease the distinction of
licenses.

Own code from the thirdparty_* repositories will also be merged into the RIOT
repository, leaving only differently licensed stuff there (or outsource this
to thirdparty vendors' repositories).

4. Features for the upcoming release
====================================
Milestone
---------
Features and changes for the next release were collected in the Milestone in
the Github Issue Tracker [1] and the corresponding Trello board [2]:
 Software Features:
 - new hardware timer abstraction module
 - POSIX timer API
 - POSIX socket wrapper and file descriptors
 - CCN
 - Integration of libCOAP
 - framework for automatic testing/continuous integration
 Hardware support:
 - Support for Econotag (almost finished)
 - Support for TelosB (almost finished) - may serve as a 16-bit reference
   platform
 - Support for the new reference hardware (e.g., deRFsam3 [3])
 - preliminary support Cortex A9
 Fixes:
 - refactoring of the network stack
 - fixing open 6LoWPAN issues

Driving high level perspective
------------------------------
On a macro perspective the participants agreed that the next release should
mainly focus on two objectives:
 - find and support a cheap available hardware platform (see
   https://github.com/RIOT-OS/RIOT/wiki/Future-Hardware-Platforms)
 - add the most important POSIX features to ease porting of existing
   (non-RIOT) code

Kaspar and Oleg agreed that using the POSIX layer should not be used for core
stuff because of added overhead.

Timer Issues
------------
Regarding the broken vtimer, it was decided to redesign an abstracted version
of hwtimers (just multiplexing it) and move it to the core module. This would
enable things like timeout for IPC message reception and select().
A more powerful timer API should be realized as a RTC module according to the
POSIX time API [4].
This module must available for all supported platforms. However, the
implementation could partly rely on RTC hardware if available.

General improvements
--------------------
The documentation must be updated and the doxygen configuration must be fixed.
All modules should be properly documented and the documentation should include
some examples.
As a side note it was agreed that working code shall not include any TODOs.

[1] https://github.com/RIOT-OS/RIOT/issues?milestone=5
[2] https://trello.com/b/ROgsipto
[3] https://shop.dresden-elektronik.de/funkmodule/funkmodule-2-4-ghz/minimodul-sam3-23t02-2.html
[4] http://pubs.opengroup.org/onlinepubs/009695399/basedefs/sys/time.h.html
-- 
Perl’s 1st theorem: for each Perl script there is a more readable equivalent assembly program.


More information about the devel mailing list