add RIOT as submodule #50
Conversation
|
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. |
| @@ -0,0 +1,3 @@ | |||
| [submodule "RIOT"] | |||
There was a problem hiding this comment.
Just add this to prevent merging before discussion. I remove it later ;)
|
Having submodules for this repo makes much sense. Would it be possible to add singe submodules for each application?
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. |
|
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. 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. |
|
so what about this one? |
|
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. |
|
@gebart fixed that |
|
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 ... |
The RIOT submodule is intended to be fixed to lastest release, in this initial state that is 2018.10. The idea is to make sure all applications compile and run with that release and the submodule is later on updated by the RIOT release manager as part of the release process.
|
please note that this is also required to activate Travis-CI later, #48 |
|
@jia200x mind to approve or dismiss your (not-needed-anymore) blocking "review" 😄 |
|
maybe a third ACK to be consistent with the RIOT repository rules? :) |
|
🎉 |
|
I added a note to the release management draft, so we (hopefully) don't forget about this repository during the release cycle ;-). |
add RIOT as submodule
This adds RIOT as a submodule fixed on the latest official release, i.e.,
2018.072018.10. It also adapts the Makefiles of the23 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.