add RIOT as submodule

[smlng]

This adds RIOT as a submodule fixed on the latest official release, i.e., 2018.07 2018.10. It also adapts the Makefiles of the 2 3 existing apps to use the submodule as RIOTBASE.

The idea would be that the submodule is bumped to the next version (RIOT release) as part of the release process and with that make sure all apps compile and run with the new release. This would help to allow problems like #47 where the app is broken because of changes to RIOT master.

[smlng]

thx @jia200x, I think this should get more than one approval, though, or at least some discussion ...

[jia200x]

thx @jia200x, I think this should get more than one approval, though, or at least some discussion ...

I agree (the ACK was intended though). We can request a small change to avoid merging by mistake.

[PeterKietzmann]

Having submodules for this repo makes much sense. Would it be possible to add singe submodules for each application?

The idea would be that the submodule is bumped to the next version (RIOT release) as part of the release process

People are planning to add further applications here, e.g., a board specific application for the SenseBox and who knows where we end up when one action leads to another... What I'm trying to say is that maybe we don't want to add this to the release procedure in the long-term.

[smlng]

@PeterKietzmann

First: having submodules per application is possible, but would also mean the actual application is in a different repository. That could be a way for third party apps that we want to expose (and test) here. This needs more thinking and discussion, how to proceed.

Second: if wee agree to add RIOT as a submodule in order to make this repo more stable, we also need to implement a process of updating this submodule in a regular fashion, which includes testing and verifying all apps compile and work. To it makes sense to make this part of the release process, which doesn't mean the release manager needs to do that but as with all the release testing may delegate this task to others.

[smlng]

so what about this one?

[jnohlgard]

I think it is a good idea to use a submodule to get some improved stability here. In my opinion, the process here should be tracking the release process in the way that the RIOT release is not affected if anything stops working in this repo, but it should be a goal to update the submodule in this repo as soon as possible after a new OS release has been made upstream, including API changes to applications, so that the submodule is always pointing to the latest stable release.

In the case where there are bigger API changes affecting these applications we could have a development branch which could be using commits from the upstream master branch for the submodule, only to make the required changes to applications easier to review. The applications dev branch would then be PR:ed into the applications master when the next stable OS release is out, to handle the upstream API changes in one single swoop.

[smlng]

@gebart fixed that

[smlng]

ping! It seems everybody kind of agrees that this is a good idea, right? So why not do this, then. I'll update to 2018.10 for now ...

[smlng]

please note that this is also required to activate Travis-CI later, #48

[smlng]

@jia200x mind to approve or dismiss your (not-needed-anymore) blocking "review" 😄

[jia200x]

maybe a third ACK to be consistent with the RIOT repository rules? :)

[jia200x]

:tada:

[miri64]

I added a note to the release management draft, so we (hopefully) don't forget about this repository during the release cycle ;-).