Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

doc/rdm: RFC - design goals #10162

Merged
merged 2 commits into from May 9, 2019

Conversation

@danpetry
Copy link
Contributor

commented Oct 15, 2018

Contribution description

This is a PR aimed at determining and recording the community's consensus on the design goals for our OS.

The primary aim of the resulting document is to help developers make design decisions that are consistent with each other, and that address the unique benefits which RIOT aims to bring to users.

In more detail, the supporting aims are:

  • To provide more detail on the design goals, to inform developers and help them make design decisions that are aligned with one another
  • To provide information on relative importance of the design goals, to inform debate where there are competing design tradeoffs
  • To increase developer focus on users, so they intuitively develop a system that is useful to end users and therefore adopted widely
  • To communicate this information efficiently, clearly and unambiguously, so that the goals are the same for everyone.

The contents of the PR as initially raised are my initial thoughts, to act broadly as conversational points. As such there is still much refinement required on the language, format and content. I expect and hope that this will get refined, changed, and will probably look substantially different from this initial state, because I would like this document to reflect the consensus of the whole community, not my own opinion.

The resulting document should be a set of guidelines, not rules. The language used in it should implicitly reflect this.

This was influenced by Hadoop and Django's mission statements and Hadoop, Rust and Django's design philosophies [1-5].

As many people contributing to this as possible would be ideal. Particularly useful would be input on the following:

  • The descriptions and requirements of the use cases
  • Whether this adequately reflects goals other than getting it into more products, such as being a demonstrator platform for IETF standards
  • Whether it suitably informs developers in making decisions on tradeoffs between competing design goals.

[1] https://hadoop.apache.org/
[2] https://www.djangoproject.com/
[3] https://hadoop.apache.org/docs/r1.2.1/hdfs_design.html#Assumptions+and+Goals
[4] https://doc.rust-lang.org/1.4.0/complement-design-faq.html#syntax
[5] https://docs.djangoproject.com/en/2.1/misc/design-philosophies/

Testing procedure

Read it!

@danpetry danpetry changed the title RFC: design goals doc/rdm: RFC - design goals Oct 15, 2018
@waehlisch waehlisch requested review from tcschmidt and waehlisch Oct 15, 2018
@danpetry danpetry force-pushed the danpetry:doc/rdm1-RIOT-design-goals branch from 9b57bad to 8fd3f18 Oct 15, 2018

## Status

This document is a product of the community of RIOT maintainers, and aims to

This comment has been minimized.

Copy link
@emmanuelsearch

emmanuelsearch Oct 15, 2018

Member

Since the document is not a consensus document yet, the first sentence should be remove for now (added when/if the document is about to be published and assigned an RDM number etc.)

This comment has been minimized.

Copy link
@emmanuelsearch

emmanuelsearch Oct 16, 2018

Member

@danpetry can you modify asap to disambiguate?

This comment has been minimized.

Copy link
@danpetry

danpetry Oct 16, 2018

Author Contributor

done

@emmanuelsearch

This comment has been minimized.

Copy link
Member

commented Oct 15, 2018

@danpetry thanks for initiating an RDM proposal!

Such an RDM could be useful, but we need to pinpoint the precise aim of the document, somewhere between the recently published journal paper, and a high level vision doc such as this doc (which needs a refresh).

I'll try to come up with a more in-depth review asap.


## Small memory footprint

RIOT aims to support constrained devices in class 1 [1]. This means that

This comment has been minimized.

Copy link
@kaspar030

kaspar030 Oct 15, 2018

Contributor

class 0!

This comment has been minimized.

Copy link
@tcschmidt

tcschmidt Oct 15, 2018

Sure? On which device of RAM << 10 KiB runs any Internet-of-Things OS?

This comment has been minimized.

Copy link
@kaspar030

kaspar030 Oct 15, 2018

Contributor

RIOT happily serves CoAP via dual-stack IPv4/IPv6 using ~3kB RAM, with room for improvement. Not with gnrc, though.

This comment has been minimized.

Copy link
@tcschmidt

tcschmidt Oct 15, 2018

Using what?
Honestly, I severely doubt this if we speak of IPv4/IPv6 + CoAP as defined in the standards. It is of course possible to send some syntactically similar packets without straining resources. But that's not IPv4/IPv6 + CoAP.
In addition, 3 kB is not << 10 KiB. The common understanding is that class 0 devices are not citizens of the IoT.

This comment has been minimized.

Copy link
@bergzand

bergzand Oct 15, 2018

Member

The common understanding is that class 0 devices are not citizens of the IoT.

The referenced RFC states that class 0 devices are probably so resource constrained that they are unable to communicate directly with the internet. So I think requiring full IPv4 or IPv6 with CoAP is not within the definition of a class 0 device anymore. If I read the rfc (maybe a bit too liberal) (a cluster of) sensor nodes communicating with a more capable proxy over a low level (wired) protocol could count as class 0 devices.

This comment has been minimized.

Copy link
@kaspar030

kaspar030 Oct 17, 2018

Contributor

Please let me refer to the fine manual: https://tools.ietf.org/html/rfc7252

Yup, 4.6, implementation note:

If an
      implementation is too constrained to allow for allocating the
      above-mentioned upper bound, it could apply the following
      implementation strategy for messages not using DTLS security:
      Implementations receiving a datagram into a buffer that is too
      small are usually able to determine if the trailing portion of a
      datagram was discarded and to retrieve the initial portion.  So,
      at least the CoAP header and options, if not all of the payload,
      are likely to fit within the buffer.  A server can thus fully
      interpret a request and return a 4.13 (Request Entity Too Large;
      see Section 5.9.2.9) Response Code if the payload was truncated.

If a request doesn't fit my buffers, returning 4.13 (Request Entity Too Large) is alright.

Stop here as this is off-topic?

This comment has been minimized.

Copy link
@danpetry

danpetry Oct 17, 2018

Author Contributor

Stop here as this is off-topic?

I would agree

RIOT aims to be usable on low-end devices currently starting at 2 KiB RAM, with increasing functionality on more powerful devices. For networked applications, RIOT currently needs a class 1 device. This means that usable RIOT applications in certain key use cases (remote sensing, for example) consume ~ 10 KiB of RAM and ~100 KiB of ROM, or less.

I would remove the first "currently" and rephrase the second sentence to "For networked applications, class 1 devices are primarily supported". Adding "currently" feels like deferring the decision. We can always revise later in another RDM if we decide on such a pivot

This comment has been minimized.

Copy link
@kb2ma

kb2ma Oct 17, 2018

Member

If i can jump in -- this thread is hitting close to home now. :-) I agree that RIOT should be able to handle a 1280b packet. However, I definitely agree that not every scenario needs to handle such a large packet size. Setting up a deployment that assumes a small packet size is a legitimate approach within an LLN where 6LoWPAN/802.15.4 packets are 128 bytes, or BLE packets can be even smaller. One of the coolest things added to RIOT's CoAP support has been the block extension (thanks Kaspar and Koen), where the application payload can be as small as 16 bytes.

At the same time, at my day job I'm trying to convince people that MQTT on a cellular mote with TCP is a bad idea. For that, it would be nice to leverage RIOT's TCP support to implement the CoAP over TCP RFC. So, I support a composable system that allows development of a solution at both ends of the spectrum. I guess that's like Linux's support from embedded systems up to supercomputers.

This comment has been minimized.

Copy link
@kb2ma

kb2ma Oct 17, 2018

Member

Just to be clear -- the block extension allows composing or decomposing a larger payload into smaller ones to adapt to these packet size constraints. :-)

This comment has been minimized.

Copy link
@tcschmidt

tcschmidt Oct 17, 2018

Just to be clear -- the block extension allows composing or decomposing a larger payload into smaller ones to adapt to these packet size constraints. :-)

Yes, but this is for efficiency. It does not ensure that my neighbor does not send some larger packets or CoAP without block mode. Let's recall the Internet design principle: "Be liberal in what you expect" ;)

Copy link

left a comment

This document is certainly a dignified no 1 memo and worth doing, when (a) sharply and correctly focused, (b) adopted as community consensus. Currently I find it needs sharpening, focusing, and corrective actions.
Key aspects I miss most: (a) standards (system and networking), (b) unified APIs.

Copy link
Member

left a comment

Some nits and comments from my side. Feel free to ignore some of my requests for rewording a sentence, could be that it is just my personal opinion in those cases.

design decisions which lead to RIOT being a widely used product.
- Otherwise communicated via word-of-mouth, which is inefficient and leads to
corruption of information
- Percieved differently by different people.

This comment has been minimized.

Copy link
@bergzand

bergzand Oct 15, 2018

Member

Perceived

This comment has been minimized.

Copy link
@danpetry

danpetry Oct 16, 2018

Author Contributor

done

a short learning curve. Those nodes are often highly constrained in power and
memory and failures cannot be tolerated due to their isolation, and the
operating system is designed to handle these constraints with fault-free long
term operation. The protocols used to communicate with them are at the leading

This comment has been minimized.

Copy link
@bergzand

bergzand Oct 15, 2018

Member

Maybe split this (those nodes...long term operation) sentence into two. Feel free to ignore

This comment has been minimized.

Copy link
@danpetry

danpetry Oct 16, 2018

Author Contributor

done

operating system is designed to handle these constraints with fault-free long
term operation. The protocols used to communicate with them are at the leading
edge of innovation in constrained and mesh networking, to ensure data is
reliably delivered between nodes and to servers.

This comment has been minimized.

Copy link
@bergzand

bergzand Oct 15, 2018

Member

My buzzword sense is tingling here. On a more serious note, to me it is not immediately clear how using "protocols that are at the leading edge of innovation" result in reliably delivered data. I would either remove the second part or maybe reword it a bit to have more synergy between the two parts of the sentence :)

This comment has been minimized.

Copy link
@danpetry

danpetry Oct 16, 2018

Author Contributor

Reworded as parts of the edit that addresses the comments above

## Environmental sensing

This requires a node to be able to wake up at a time of the order of hours and
deliver a data point. This node should be able to operate, without being

This comment has been minimized.

Copy link
@bergzand

bergzand Oct 15, 2018

Member

Maybe change "data point" to "measurement" or "measurements", a node could do a single measurement of multiple types such as temperature, humidity, CO2 and so on.

This comment has been minimized.

Copy link
@danpetry

danpetry Oct 16, 2018

Author Contributor

Added

This requires a node to last for a number of weeks without recharge, for example
to continue operating if a user is on holiday. It should be able to send fairly
continuous data over a widely supported wireless LAN protocol, in order to
support commercial home gateways.

This comment has been minimized.

Copy link
@bergzand

bergzand Oct 15, 2018

Member

is this support as in work together with a commercial home gateway?

This comment has been minimized.

Copy link
@danpetry

danpetry Oct 16, 2018

Author Contributor

Yes, changed


This requires RIOT to support popular emerging low-power protocols, and to
provide robust and stable support for commonly used microcontrollers and
transcievers.

This comment has been minimized.

Copy link
@bergzand

bergzand Oct 15, 2018

Member

This doesn't really sound like a scenario to me, more like a requirement

This comment has been minimized.

Copy link
@danpetry

danpetry Oct 16, 2018

Author Contributor

Well, the title is a scenario and the body is a requirement. Does that answer your question? Should these all be maybe couched as: one sentence describing scenario, and one describing requirement?
By the way, a few of these are derived from actual RIOT based products, for example: https://www.unwireddevices.com/products/
I'm planning to send out an alert on the developer mailing list when discussion between core maintainers has settled down a bit, to get input from e.g. the people who actually make RIOT-based products.

doc/memos/rdm-draft-petry-riot-design-goals.md Outdated Show resolved Hide resolved
@bergzand

This comment has been minimized.

Copy link
Member

commented Oct 15, 2018

I was thinking, does it make sense to add a scenario without network capabilities? Something like a sensor with a small display attached. While RIOT is aimed at wireless sensor application, it is perfectly possible to run RIOT without any networking capabilities and enjoy the other features provided by RIOT.

@kaspar030

This comment has been minimized.

Copy link
Contributor

commented Oct 15, 2018

I was thinking, does it make sense to add a scenario without network capabilities?

Yes, I thought the same! RIOT should also be the go-to solution for any non-networked constrained device hacking.


## Abstract

This memo describes RIOT's high level design goals. The aim is to reflect

This comment has been minimized.

Copy link
@tcschmidt

tcschmidt Oct 15, 2018

Better: "the high level design goals of RIOT".

This comment has been minimized.

Copy link
@danpetry

danpetry Oct 16, 2018

Author Contributor

done


## Introduction

The primary aim of this document is to guide lower level debate and discussion.

This comment has been minimized.

Copy link
@tcschmidt

tcschmidt Oct 15, 2018

What are lower level debate? Maybe crispen this para

This comment has been minimized.

Copy link
@danpetry

danpetry Oct 16, 2018

Author Contributor

I've done another pass on this section, please review again if possible


RIOT is an open-source operating system which makes it easy to deploy sensor and
actuator networks with challenging resource requirements that can operate for
years without physical intervention.

This comment has been minimized.

Copy link
@tcschmidt

tcschmidt Oct 15, 2018

and communicate via common Internet standards.

This comment has been minimized.

Copy link
@danpetry

danpetry Oct 16, 2018

Author Contributor

done


It is designed to abstract away the hardware details of remote and low-access
sensor and actuator nodes. An identical programming interface is presented
across heterogeneous nodes, supporting underlying hardware out-of-the-box, with

This comment has been minimized.

Copy link
@tcschmidt

tcschmidt Oct 15, 2018

key aspect: Portability across hardware platforms

This comment has been minimized.

Copy link
@kaspar030

kaspar030 Oct 16, 2018

Contributor

yes, and to me the lack of any vendor lock-in is very important.

This comment has been minimized.

Copy link
@danpetry

danpetry Oct 16, 2018

Author Contributor

I've added the comments. I propose that everyone adds what they want to this section and then we refine it after additions have settled down

memory and failures cannot be tolerated due to their isolation, and the
operating system is designed to handle these constraints with fault-free long
term operation. The protocols used to communicate with them are at the leading
edge of innovation in constrained and mesh networking, to ensure data is

This comment has been minimized.

Copy link
@tcschmidt

tcschmidt Oct 15, 2018

don't think we aim for bleeding edge.
We aim at a timely support of the common Internet standards as they emerge.

This comment has been minimized.

Copy link
@kaspar030

kaspar030 Oct 16, 2018

Contributor

Well, some standards we support have been followed and influenced by core members of the community, and the first implementations are often based on drafts. Doesn't that count as leading edge? What would?

This comment has been minimized.

Copy link
@tcschmidt

tcschmidt Oct 16, 2018

I cannot remember of any example (except the ICN case) where we have been the leading edge in bringing new protocols to the IoT. Conversely, in some cases like CoAP we have been rather late. However, I don't think that it is a key design objective to be the first who implements. Rather, quality and timeliness seem the relevant focus points here.

This comment has been minimized.

Copy link
@waehlisch

waehlisch Oct 16, 2018

Member

+1 quality and timeliness should be the focus.

That some RIOTers are involved in the IETF is nice but cannot be applied to the whole RIOT community.

This comment has been minimized.

Copy link
@bergzand

bergzand Oct 16, 2018

Member

I agree with this.

The only thing I would like to emphasize in this discussion is that quality doesn't mean that the implementation is feature complete. We don't always want or require a feature complete implementation of a protocol due to the constrained environment we're working with.

This comment has been minimized.

Copy link
@danpetry

danpetry Oct 16, 2018

Author Contributor

I've edited to reflect the consensus here, feel free to keep discussing.

This comment has been minimized.

Copy link
@tcschmidt

tcschmidt Oct 16, 2018

Mhmm, again I believe this relates to the situation of interoperability and standards. Looking at the core IPv6, I don't think any IoT node really needs to implement path-MTU discovery - interoperability works without. But a node MUST implement 6Low fragmentation, if it wants to support the corresponding links. Conversely, it need not implement 6Low fragmentation if it only supports NB-IOT links ...

Its probably more a question of paraphrasing: If an implementation lacks features that are essential for interoperability, we cannot claim more than a "partial implementation". If we claim implementation of a protocol, then it must be interoperable as defined in the standards.

This comment has been minimized.

Copy link
@bergzand

bergzand Oct 16, 2018

Member

@tcschmidt I think we agree here, just wanted to emphasize that the "quality" as mentioned above doesn't imply that we must implement all the "SHOULD"s and "MAY"s from an RFC.


## Modularity

Logical separation of the different modules of RIOT enables a highly distributed

This comment has been minimized.

Copy link
@tcschmidt

tcschmidt Oct 15, 2018

The big thing about modules is first: Tailor the OS to user-specific needs.

This comment has been minimized.

Copy link
@danpetry

danpetry Oct 16, 2018

Author Contributor

Added

balance to be struck, however: too fine-grained can come at a cost of
unnecessary complexity, higher resources, and difficulty of understanding.

## Independence of the underlying hardware

This comment has been minimized.

Copy link
@tcschmidt

tcschmidt Oct 15, 2018

Better: Hardware abstraction and cross-hardware portability

This comment has been minimized.

Copy link
@danpetry

danpetry Oct 16, 2018

Author Contributor

Changed

Development should be able to be done once and run on any platform using RIOT.
To achieve this with reduced development effort in porting, the hardware is
abstracted and the APIs are uniform at as low a level as possible.

This comment has been minimized.

Copy link
@tcschmidt

tcschmidt Oct 15, 2018

Would add:

Robustness and resilience

Versatility

Unified APIs

This comment has been minimized.

Copy link
@danpetry

danpetry Oct 16, 2018

Author Contributor

I've added these sections with some initial text for further refinement.

This comment has been minimized.

Copy link
@waehlisch

waehlisch Jan 30, 2019

Member

I'm not sure if I like the order of the subsections. For example, the current text in "Versatility" reads like high-order insights that should be moved to the beginning of this section.

# References

[1] [IETF RFC 7228: Terminolgy for Constrained-Node Networks](https://tools.ietf.org/html/rfc7228)

This comment has been minimized.

Copy link
@tcschmidt

tcschmidt Oct 15, 2018

Should add reference to
(1) RIOT initial Infocom poster
(2) RIOT journal (s. @emmanuelsearch )

This comment has been minimized.

Copy link
@danpetry

danpetry Oct 16, 2018

Author Contributor

Added.

doc/memos/rdm-draft-petry-riot-design-goals.md Outdated Show resolved Hide resolved
@tcschmidt

This comment has been minimized.

Copy link

commented Oct 15, 2018

I was thinking, does it make sense to add a scenario without network capabilities?

Yes, I thought the same! RIOT should also be the go-to solution for any non-networked constrained device hacking.

Mhmm, is that of interest? Real, standard-conformal networking is a key objective of RIOT ... and there is no IoT without networking according to open standards.

@bergzand

This comment has been minimized.

Copy link
Member

commented Oct 15, 2018

Mhmm, is that of interest? Real, standard-conformal networking is a key objective of RIOT ... and there is no IoT without networking according to open standards.

Exactly, I fully agree!

But I also think that using RIOT without any network capabilities is a perfectly valid use case. This might not be "IoT" anymore, but does that really matter? If my requirements are such that I need a small embedded operating system that is able to do real time via preemptive priority based threads, RIOT is a good option to pick in my opinion.

@miri64

This comment has been minimized.

Copy link
Member

commented Oct 15, 2018

Agreed RIOT without IoT might sound non-sensical to some, but a completely unconnected node should still be a possibility as it is a valid use-case (look at most Arduinos: they come without any radio and still people use them in their prototypes (TM) for controlling (unconnected) things).

@kaspar030

This comment has been minimized.

Copy link
Contributor

commented Oct 16, 2018

a completely unconnected node should still be a possibility as it is a valid use-case (look at most Arduinos: they come without any radio and still people use them in their prototypes (TM) for controlling (unconnected) things).

Yes, and some of RIOT's main selling points are independent of networking: strong community, FOSS code, efficient portable API's without vendor lock-in, nice selection of libraries and/or packages curated from a central source, well-rounded package of kernel functionality, ...

@emmanuelsearch

This comment has been minimized.

Copy link
Member

commented Oct 16, 2018

I'm wondering if we should not consider splitting such a document in 2 different docs.

  • a document that would be about high level mission statement and generic targets (aligned with section 3 of the journal paper);
  • another document that would survey (actual and potential) use cases of RIOT.

The reasoning for this: I think the second document could be very useful.
Moreover, it is difficult to elegantly mix a list of use-cases, with general mission statements.
And: this would make for shorter, crisper docs.
Any opinions on this?


## Status

This document is a product of the community of RIOT maintainers, and aims to

This comment has been minimized.

Copy link
@emmanuelsearch

emmanuelsearch Oct 16, 2018

Member

@danpetry can you modify asap to disambiguate?

@danpetry

This comment has been minimized.

Copy link
Contributor Author

commented Feb 21, 2019

Great. I've pushed this changes along with others which aim to address all comments so far.

Copy link
Contributor

left a comment

Thanks for working on this! Just some small comments below.

doc/memos/rdm-draft-petry-riot-design-goals.md Outdated Show resolved Hide resolved
doc/memos/rdm-draft-petry-riot-design-goals.md Outdated Show resolved Hide resolved
@danpetry danpetry force-pushed the danpetry:doc/rdm1-RIOT-design-goals branch from ac0e3d6 to b7c1637 Mar 27, 2019
@danpetry

This comment has been minimized.

Copy link
Contributor Author

commented Apr 30, 2019

@miri64 @waehlisch @tcschmidt @emmanuelsearch in particular, but anyone else reading this as well:

Is there anything in this document in its current state that you are not able to live with? Which you would consider problematic? If so, could you explain your reasons?

If not, and you have an open review, could you remove the mechanical block on merging either by approving the review or dismissing it? Since there are three ACKs required to merge this, there is a choice about how to remove the block: by indicating support for the document or by indicating apathy. If there are changes that would result in support rather than apathy, and you are willing to discuss those changes, that would be welcomed and preferred.

Copy link
Member

left a comment

@danpetry @tcschmidt @waehlisch @kaspar030 @miri64 @bergzand
While there is still some room for improvement, I propose we merge this once the last comments (easy to address) are fixed.
We can improve the doc later, with subsequent revisions, as permitted by RDM life-cyle.
Opinions on this way to proceed?

RIOT is a general purpose IoT operating system for low-end devices, such as
those described in [1]. These devices have a low memory footprint - kilobytes
rather than megabytes - and an extremely low memory footprint of a few
kilobytes in certain applications. As such, RIOT targets separate use cases from

This comment has been minimized.

Copy link
@emmanuelsearch

emmanuelsearch May 2, 2019

Member

@danpetry seems like a copy/paste issue here (twice mentioning memory in the sentence?).

I propose rephrasing:

These devices have an extremely low memory footprint - kilobytes rather than megabytes or gigabytes - and are typically based on low-power microcontrollers lacking hardware features provided on less constrained devices e.g. an MMU. 

This comment has been minimized.

Copy link
@danpetry

danpetry May 2, 2019

Author Contributor

This wasn't a copy/paste error: the idea was to say
a) our targeted devices all have ~kilobytes of memory
b) our targeted devices go down to a very small number of kilobytes in certain cases
Does that clarify and do you agree?

This comment has been minimized.

Copy link
@danpetry

danpetry May 3, 2019

Author Contributor

Have clarified to:
These devices have a low memory footprint of kilobytes rather than megabytes, going down to a few kilobytes in certain cases.
Does that read better and make the meaning more apparent?

doc/memos/rdm-draft-petry-riot-design-goals.md Outdated Show resolved Hide resolved

Modules outside the core should leverage the benefits and address the
programming challenges of such a scheduler, without demanding that users do the
same. An idling device should conserve energy wherever possible, by default.

This comment has been minimized.

Copy link
@emmanuelsearch

emmanuelsearch May 2, 2019

Member

this sentence is difficult to parse.
How about splitting it in 2 parts? Maybe something like

  1. developers of modules should...
  2. users should be able to benefit from RIOT's energy efficiency mechanisms without having to cope with scheduler details or setting power modes explicitly.

This comment has been minimized.

Copy link
@danpetry

danpetry May 2, 2019

Author Contributor

So eg:
Developers of modules outside the core should leverage the benefits and address the
programming challenges of such a scheduler. An idling device should conserve energy wherever possible, by default. For case specific power management, appropriate control should be available to the user. This should not include having to cope with scheduler details or set hardware power modes explicitly.

This comment has been minimized.

Copy link
@danpetry

danpetry May 3, 2019

Author Contributor

changed to the above, let me know if not good

@danpetry

This comment has been minimized.

Copy link
Contributor Author

commented May 2, 2019

We can improve the doc later, with subsequent revisions, as permitted by RDM life-cyle.

To remind: RDM processes state that revisions to the document would only be to clarify, rather than change the intended meaning. Also that a doc shouldn't be merged if there are expected changes.

I would say it's up to you if you want to raise further comments. I think that before we merge, it should be in a state where the community can use it, and there's nothing in there that is a big problem for anyone in their work.

@danpetry

This comment has been minimized.

Copy link
Contributor Author

commented May 2, 2019

Thanks for the acks @emmanuelsearch and @waehlisch !

Copy link

left a comment

O.K. also from my side

@miri64 miri64 dismissed their stale review May 3, 2019

My comments were addressed

@miri64

This comment has been minimized.

Copy link
Member

commented May 3, 2019

Since there are three ACKs I think you can squash.

@danpetry danpetry force-pushed the danpetry:doc/rdm1-RIOT-design-goals branch from 7374130 to 0eddd1b May 3, 2019
@miri64

This comment has been minimized.

Copy link
Member

commented May 3, 2019

I guess we need to rename it before merging still, right?

@danpetry danpetry force-pushed the danpetry:doc/rdm1-RIOT-design-goals branch 2 times, most recently from 4eb66c9 to ca86557 May 3, 2019
danpetry added 2 commits May 3, 2019
Initial commit of document.
danpetry
Update README to include a reference to the new document.
@danpetry danpetry force-pushed the danpetry:doc/rdm1-RIOT-design-goals branch from ca86557 to c3bd937 May 3, 2019
@danpetry

This comment has been minimized.

Copy link
Contributor Author

commented May 3, 2019

Renamed, updated pre and postambles to the format described in RDM0, and updated the table of contents in the README.

I think someone should check that I've done this correctly before we merge... any volunteers please? :)

@miri64

This comment has been minimized.

Copy link
Member

commented May 3, 2019

I think one of the three acking maintainers should do that.

@emmanuelsearch

This comment has been minimized.

Copy link
Member

commented May 9, 2019

Looks fine in terms of format. Go!

@emmanuelsearch emmanuelsearch merged commit 793072c into RIOT-OS:master May 9, 2019
2 checks passed
2 checks passed
Murdock The build succeeded. runtime: 15m:49s
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.