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

Design process and template for Mbed-OS #7561

Merged
merged 6 commits into from Sep 1, 2018

Conversation

@SenRamakri
Contributor

SenRamakri commented Jul 19, 2018

Description

This documents the software design process for Mbed-OS. Anyone developing for Mbed-OS can use this process to submit the design to get it reviewed from the broader Mbed-OS developer community. This change contains documentation on the process, design template and an example design document. The template is developed based on the philosophy that it should capture the details of software design and not how the development itself is tracked/tested. Please look at below docs for more info:

Design Process:
https://github.com/ARMmbed/mbed-os/pull/7561/files#diff-43cd5a0825320bdbd0598823eeb945ab

Design Template:
https://github.com/ARMmbed/mbed-os/pull/7561/files#diff-a494f1e71adb00e6a436fa9d963fb214

Example Design Document:
https://github.com/ARMmbed/mbed-os/pull/7561/files#diff-44bf7630a4f8e06c3c8cb9e9d5659b75

Pull request type

[ ] Fix
[ ] Refactor
[ ] New target
[x] Feature
[ ] Breaking change
@cmonr

This comment has been minimized.

Contributor

cmonr commented Jul 20, 2018

@SenRamakri I'll put this in my queue for review for tomorrow, but I do want to ask, is there a reason that this is coming into this repo instead of the Handbook?

@cmonr cmonr requested a review from AnotherButler Jul 20, 2018

@cmonr cmonr added the needs: review label Jul 20, 2018

@SenRamakri

This comment has been minimized.

Contributor

SenRamakri commented Jul 20, 2018

@cmonr - Good question, there are few good reasons for this to be in mbed-os repo. The idea is to have design documents in the same location where the corresponding implementation is and these are supposed to be living documents and capturing updates to the implementation anytime. Also the current model for the docs repo is to publish with each mbed-os release(as htmls) under os.mbed.com. Design documents can come in and can change any time and may not fit that use case. It also makes sense for developers to use single repo with code and its design documents as they will be working on both of them in unison and also helps with easy cross-reference. Also being in same repo helps with binding the specific versions of design document to the version of code changes, this will be tough if they end up in different repo. Thus, it makes sense for us to keep the process/template in mbed-os itself where developers can easily find/adopt it. Hope this answers the question.

- [Custom Headings Here](#custom-headings-here)

### Revision history
1.0 - A brief description for this version, e.g. Initial revision - Author name - Date

This comment has been minimized.

@0xc0170

0xc0170 Jul 20, 2018

Member

do we need revision here? It's in git so we see what has changed and when. No need to version this document like this

This comment has been minimized.

@SenRamakri

SenRamakri Jul 20, 2018

Contributor

@0xc0170 - I think we need the revision here because an author can make multiple changes in github to capture the new ideas or to match the implementation. But they all might point to one logical design. That's why I thought a revision here makes sense. For example, some one might push a change and then may decide to make some typo fixes/minor interface name changes which will be updated into the document. But it doesn't change the design logically. Its more like major design version and git versioning will be more like minor versioning.

This comment has been minimized.

@bulislaw

bulislaw Aug 8, 2018

Member

Should we put it at the end like in IETF RFC? I would say it's not something you want to read first.

This comment has been minimized.

@donatieng

donatieng Aug 8, 2018

Member

If we keep a revision number (as opposed to using git) we need to agree on what it should be. Maybe it's more appropriate to say: "This document's revision addresses Mbed OS 5.10 onwards"? That way it's more understandable to see what versions of the OS this document addresses.

@@ -0,0 +1,40 @@
# Design Process for Mbed-OS
This document defines the software design process for Mbed-OS. Anyone developing for Mbed-OS should use this process to submit the design to get it reviewed from the broader Mbed-OS developer community.

This comment has been minimized.

@0xc0170

0xc0170 Jul 20, 2018

Member

What does it mean "design" ?

When to use this process? When I do large refactor or want to submit new feature or change user API? HAL change?

This comment has been minimized.

@SenRamakri

SenRamakri Jul 20, 2018

Contributor

Its up to the developer to make a judgement on whether a design doc is required for a change. For small changes its definitely not required. But for changes with lot of code turmoil its best to have a backing design document. Let me try to see if we can update the process document to capture this guideline.

This comment has been minimized.

@donatieng

donatieng Aug 8, 2018

Member

I think it's "Mbed OS" (as opposed to "Mbed-OS") ;)

* It's suggested to write one design document per change, which could be a new feature, defect fixes, tools changes etc. Do not try to address multiple changes in the same document.
* The design document will follow the format represented in [Design Document Template](https://github.com/ARMmbed/mbed-os/blob/master/docs/design-documents/design_template.md)

* For each design submission, create a folder under *https://github.com/ARMmbed/mbed-os/docs/design-documents/{AREA OR COMPONENT}*. The area/component would be Drivers, Platform, Connectivity, Security, Peripherals etc.

This comment has been minimized.

@0xc0170

0xc0170 Jul 20, 2018

Member

Do we have areas/components listed anywhere? We got similar problem in labels here on github. I would like to document them and use them here/labels/elsewhere

This comment has been minimized.

@SenRamakri

SenRamakri Jul 20, 2018

Contributor

That's good idea, we can make a initial list. It can be expanded later as well.

* For each design submission, create a folder under *https://github.com/ARMmbed/mbed-os/docs/design-documents/{AREA OR COMPONENT}*. The area/component would be Drivers, Platform, Connectivity, Security, Peripherals etc.
If your implementation is creating new APIs, you should try to match the folder name directly to the new API, otherwise
use the title of the feature as the folder name.
For example, if your implementation is adding new EMAC API, you may name the folder as **New_EMAC_API** or if you are creating a new Serial Driver for Mbed-OS you may name the folder as **Serial_driver_for_Mbed-os**.

This comment has been minimized.

@0xc0170

0xc0170 Jul 20, 2018

Member

I would vote for lower case naming new_emac_api

This comment has been minimized.

@SenRamakri

SenRamakri Jul 20, 2018

Contributor

Well the folder name also serve as the title, that's why I thought it should be capitalized as required.
If more people align with lower_case we can definitely change it.

This comment has been minimized.

@bulislaw

bulislaw Aug 7, 2018

Member

I'd rather not have 100 folders. We should match it somehow to Mbed OS repo structure.

This comment has been minimized.

@donatieng

donatieng Aug 8, 2018

Member

Yes - hopefully for new features within a component we can just make pull requests that update the existing design doc? Also do we really need design documents for fixes?

Its highly encouraged to create diagrams to depict your software design. The [Design Document Template]((https://github.com/ARMmbed/mbed-os/blob/master/docs/design-documents/design_template.md) provided here uses diagrams generated using draw.io. draw.io generates XMLs for each diagram and those corresponding XMLs are also provided under the diagrams folder, and you are free to use that as your reference for generating your own diagrams. And, when you are generating your own diagrams it would be better to provide the metadata/other files(e.g, if you are using draw.io provide XMLs from draw.io) required for future editing of those diagrams.

## Design Process
* Developer generates a design document located under *https://github.com/ARMmbed/mbed-os/docs/design-documents/{AREA OR COMPONENT}* and generates a pull-request to Mbed-OS.

This comment has been minimized.

@0xc0170

0xc0170 Jul 20, 2018

Member

Would this be rather : first github issue to discuss the idea (gather feedback) - is it worth my and yours time? Then take time to write it down and create PR with the design specifications

This comment has been minimized.

@SenRamakri

SenRamakri Jul 20, 2018

Contributor

Its ok for developers to gather feedback on some idea if they want, which I think is already happening. But when they have decided to go ahead implement the idea a design document could be generated to capture more details and for later reference.

This comment has been minimized.

@0xc0170

0xc0170 Jul 23, 2018

Member

Its ok for developers to gather feedback on some idea if they want, which I think is already
happening.

I was after if someone already put effort to write down and it gets rejected - I have seen it with pull requests that contained lot of effort but were rejected - maybe my question should have been : when is design document approved and integrated (as well when its rejected and closed) ? How to maximize the success of the design document. I believe ideally it would be if issue gets enough traction and +1 from involved parties, design document would be approved and later implemented.

This comment has been minimized.

@bulislaw

bulislaw Aug 7, 2018

Member

I would say extra issue is redundant. Explain your idea in this RFC straight away. Maybe it's worth pointing out that the initial submission of the RFC doesn't need to be complete and refined.

- [Custom Headings Here](#custom-headings-here)

### Revision history
1.0 - A brief description for this version, e.g. Initial revision - Author name - Date

This comment has been minimized.

@0xc0170

0xc0170 Jul 20, 2018

Member

this revision history is not needed here (sufficient to have it in git)

This comment has been minimized.

@SenRamakri

SenRamakri Jul 20, 2018

Contributor

Please see my comment above.

It's possible that a new implementation may require changes to some previous implementations. In that case, capture
the new changes in the original design document as well. Also create references to other(or older) design documents in the
References section for the new design document.

This comment has been minimized.

@0xc0170

0xc0170 Jul 20, 2018

Member

I comment here but it comes after design phase - what about the implementation ? Is author expected to implement, or rather anyone can do, etc. I think a section here would be sufficient about "after design doc is accepted"

This comment has been minimized.

@SenRamakri

SenRamakri Jul 20, 2018

Contributor

No really, its possible that design document author could be different from implementer. In fact, that's where the document really helps. If the document is detailed enough, anyone can take the document and go do the implementation. Its not absolutely necessary that implementation should be started only after design document review. The only guideline here is if there is change to design it will impact your implementation as well, and thus for large features where lot of design feedbacks are expected it's advisable to start your implementation once major feedbacks are captured. Again, its up to the implementer to make that judgement depending on how big/which part of mbed-os the feature is. For example, API designs can be very intensive and may drastically change over the period of review. In those cases, its best to delay your major implementation cycle until that agreement is reached. But for very localized implementations not impacting other parts of the system/application writers it may be ok to have an implementation initially along with design document.

This comment has been minimized.

@0xc0170

0xc0170 Jul 23, 2018

Member

Correct, I was looking for an answer : what are the next steps after design document is accepted. I would expect this question once first design doc from community is accepted. "What's next?"

What I was thinking here - post design doc accepted. Firstly, design docs are assigned priority. If it's high, we would like to have it implemented right away - either by us or community. Lower priority, will wait for implementation (welcome to do by anyone anytime).

A paragraph describing "next possible steps" . What others think?

@SenRamakri

This comment has been minimized.

Contributor

SenRamakri commented Jul 20, 2018

@0xc0170 - Thanks for your review and I have added a general guidelines section which might help answer some of the concerns you raised. Please take a look.

@iriark01

This comment has been minimized.

Contributor

iriark01 commented Jul 23, 2018

@SenRamakri just one comment: we can publish docs at any time (every 10min or so), we don't have to wait a full quarter. So that in itself is not a reason not to put them in the docs repo.

@SenRamakri

This comment has been minimized.

Contributor

SenRamakri commented Jul 23, 2018

@0xc0170 - I agree that we can technically publish docs anytime. But my point is we still have to take another step to get it published(like generating the html and deploying). But, design-docs here is immediately available when merged and can be pull-ed into local repos.

```C
char in_byte = 0;
int num_bytes_read = read(&in_byte, 1);
if(num_bytes_read == 1) {

This comment has been minimized.

@0xc0170

0xc0170 Jul 25, 2018

Member

if () - space there (check also the rest of the examples) so they follow our code style

@SenRamakri SenRamakri requested a review from donatieng Jul 25, 2018

@bulislaw

I've reviewed the README, I'll do the rest tomorrow.

* For each design submission, create a folder under *https://github.com/ARMmbed/mbed-os/docs/design-documents/{AREA OR COMPONENT}*. The area/component would be Drivers, Platform, Connectivity, Security, Peripherals etc.
If your implementation is creating new APIs, you should try to match the folder name directly to the new API, otherwise
use the title of the feature as the folder name.
For example, if your implementation is adding new EMAC API, you may name the folder as **New_EMAC_API** or if you are creating a new Serial Driver for Mbed-OS you may name the folder as **Serial_driver_for_Mbed-os**.

This comment has been minimized.

@bulislaw

bulislaw Aug 7, 2018

Member

I'd rather not have 100 folders. We should match it somehow to Mbed OS repo structure.

Its highly encouraged to create diagrams to depict your software design. The [Design Document Template]((https://github.com/ARMmbed/mbed-os/blob/master/docs/design-documents/design_template.md) provided here uses diagrams generated using draw.io. draw.io generates XMLs for each diagram and those corresponding XMLs are also provided under the diagrams folder, and you are free to use that as your reference for generating your own diagrams. And, when you are generating your own diagrams it would be better to provide the metadata/other files(e.g, if you are using draw.io provide XMLs from draw.io) required for future editing of those diagrams.

## Design Process
* Developer generates a design document located under *https://github.com/ARMmbed/mbed-os/docs/design-documents/{AREA OR COMPONENT}* and generates a pull-request to Mbed-OS.

This comment has been minimized.

@bulislaw

bulislaw Aug 7, 2018

Member

I would say extra issue is redundant. Explain your idea in this RFC straight away. Maybe it's worth pointing out that the initial submission of the RFC doesn't need to be complete and refined.


## Design Process
* Developer generates a design document located under *https://github.com/ARMmbed/mbed-os/docs/design-documents/{AREA OR COMPONENT}* and generates a pull-request to Mbed-OS.
* NOTE: If you are part of an organization and would like to do design review within your organization before landing the pull-request, its ok to do so.

This comment has been minimized.

@bulislaw

bulislaw Aug 7, 2018

Member

Do we really need this point I think it's rather obvious.

This comment has been minimized.

@donatieng
## Design Process
* Developer generates a design document located under *https://github.com/ARMmbed/mbed-os/docs/design-documents/{AREA OR COMPONENT}* and generates a pull-request to Mbed-OS.
* NOTE: If you are part of an organization and would like to do design review within your organization before landing the pull-request, its ok to do so.
* The pull request may also include the initial code implementation. It's upto to the develper to decide if the initial implementation comes along with the design document or later.

This comment has been minimized.

@bulislaw

bulislaw Aug 7, 2018

Member

I would mention that it's advisable to start with a basic outline of an idea, so people can discuss it and then refine it.

This comment has been minimized.

@donatieng

donatieng Aug 8, 2018

Member

I feel like these should be two separate PRs - otherwise you'll have to update the code implementation in sync with each change to the spec.

For NFC we have a PR up for the spec + an internal PR with the API. We rebase the API branch regularly against the spec branch.

* Once the design is approved, implementation is completed/adjusted according to the latest design document. Developer can create the pull-request with the final implementation, if its coming separately.

## Capturing future changes to design
If your implementation changes in future, corresponsding design documents may be updated to capture the new design.

This comment has been minimized.

@bulislaw

bulislaw Aug 7, 2018

Member

may -> should? should be updated

This comment has been minimized.

@donatieng

donatieng Aug 8, 2018

Member

"corresponsding"

@bulislaw

Great work! It looks good. Some general suggestion, the README should be rather small I would say. The process should be defined here https://os.mbed.com/docs/v5.9/reference/software-design.html and guide people through the process. The README should probably reference it and possibly add some hints. We should also get it reviewed by the docs team.

# Mbed-OS Design Document
Write your feature title above, in this case its "Mbed-OS Design Document"

# Table of Contents

This comment has been minimized.

@bulislaw

bulislaw Aug 8, 2018

Member

Do we really need this, it feels like a high maintenance part.

This comment has been minimized.

@SenRamakri

SenRamakri Aug 8, 2018

Contributor

The contents makes it really easy to navigate for large documents. Also makes it easy to see the context specific sections as we let authors to add specific sub-sections as they want.

This comment has been minimized.

@SenRamakri

SenRamakri Aug 8, 2018

Contributor

Yes, I think contents really makes it easy for large docs and to find the sections. Please see my previous comment.

- [Custom Headings Here](#custom-headings-here)

### Revision history
1.0 - A brief description for this version, e.g. Initial revision - Author name - Date

This comment has been minimized.

@bulislaw

bulislaw Aug 8, 2018

Member

Should we put it at the end like in IETF RFC? I would say it's not something you want to read first.

* `Reading from and Writing to the device` - Read and Write interfaces should be implemented to support sending single/multiple bytes.
* `Resetting the device` - Functionality to reset the device should be provided.

**NOTE: If you already have supporting architecture documentation in the form of technology documents or other existing documents

This comment has been minimized.

@bulislaw

bulislaw Aug 8, 2018

Member

We should make clear it has to be public.

@donatieng

Great stuff @SenRamakri :). I have a few comments below.

@@ -0,0 +1,40 @@
# Design Process for Mbed-OS
This document defines the software design process for Mbed-OS. Anyone developing for Mbed-OS should use this process to submit the design to get it reviewed from the broader Mbed-OS developer community.

This comment has been minimized.

@donatieng

donatieng Aug 8, 2018

Member

I think it's "Mbed OS" (as opposed to "Mbed-OS") ;)

* For each design submission, create a folder under *https://github.com/ARMmbed/mbed-os/docs/design-documents/{AREA OR COMPONENT}*. The area/component would be Drivers, Platform, Connectivity, Security, Peripherals etc.
If your implementation is creating new APIs, you should try to match the folder name directly to the new API, otherwise
use the title of the feature as the folder name.
For example, if your implementation is adding new EMAC API, you may name the folder as **New_EMAC_API** or if you are creating a new Serial Driver for Mbed-OS you may name the folder as **Serial_driver_for_Mbed-os**.

This comment has been minimized.

@donatieng

donatieng Aug 8, 2018

Member

Yes - hopefully for new features within a component we can just make pull requests that update the existing design doc? Also do we really need design documents for fixes?

See [Example Design Document](https://github.com/ARMmbed/mbed-os/blob/master/docs/design-documents/example_feature_design/example_feature_design.md) for example design document.

### Using diagrams in Design documents
Its highly encouraged to create diagrams to depict your software design. The [Design Document Template]((https://github.com/ARMmbed/mbed-os/blob/master/docs/design-documents/design_template.md) provided here uses diagrams generated using draw.io. draw.io generates XMLs for each diagram and those corresponding XMLs are also provided under the diagrams folder, and you are free to use that as your reference for generating your own diagrams. And, when you are generating your own diagrams it would be better to provide the metadata/other files(e.g, if you are using draw.io provide XMLs from draw.io) required for future editing of those diagrams.

This comment has been minimized.

@donatieng

donatieng Aug 8, 2018

Member

For the NFC design spec we're using plantUML/plantText which lets your describe UML diagrams in text formats (and therefore make them easily versionable)

This comment has been minimized.

@SenRamakri

SenRamakri Aug 8, 2018

Contributor

Thats great point, draw.io was only an example. Engineers are ok to use their favorite tools.


## Design Process
* Developer generates a design document located under *https://github.com/ARMmbed/mbed-os/docs/design-documents/{AREA OR COMPONENT}* and generates a pull-request to Mbed-OS.
* NOTE: If you are part of an organization and would like to do design review within your organization before landing the pull-request, its ok to do so.

This comment has been minimized.

@donatieng
## Design Process
* Developer generates a design document located under *https://github.com/ARMmbed/mbed-os/docs/design-documents/{AREA OR COMPONENT}* and generates a pull-request to Mbed-OS.
* NOTE: If you are part of an organization and would like to do design review within your organization before landing the pull-request, its ok to do so.
* The pull request may also include the initial code implementation. It's upto to the develper to decide if the initial implementation comes along with the design document or later.

This comment has been minimized.

@donatieng

donatieng Aug 8, 2018

Member

I feel like these should be two separate PRs - otherwise you'll have to update the code implementation in sync with each change to the spec.

For NFC we have a PR up for the spec + an internal PR with the API. We rebase the API branch regularly against the spec branch.

* Developer generates a design document located under *https://github.com/ARMmbed/mbed-os/docs/design-documents/{AREA OR COMPONENT}* and generates a pull-request to Mbed-OS.
* NOTE: If you are part of an organization and would like to do design review within your organization before landing the pull-request, its ok to do so.
* The pull request may also include the initial code implementation. It's upto to the develper to decide if the initial implementation comes along with the design document or later.
* Although, if you are planning a large change, its encoraged to start the design review early before the implementation. This also help to avoid major re-work of your implementation if required by the design review.

This comment has been minimized.

@donatieng

donatieng Aug 8, 2018

Member

"encoraged" -> "encouraged" / "help" -> "helps"

* Once the design is approved, implementation is completed/adjusted according to the latest design document. Developer can create the pull-request with the final implementation, if its coming separately.

## Capturing future changes to design
If your implementation changes in future, corresponsding design documents may be updated to capture the new design.

This comment has been minimized.

@donatieng

donatieng Aug 8, 2018

Member

"corresponsding"

References section for the new design document.

## General guidelines for creating design documents
Its up to the developer to make a judgement on whether a design docucment is required for a change. It may not be required for minor fixes and small localized changes. But for changes with lot of code turmoil across multiple components or if its new feature or functionality being added its best to have a backing design document. Its also ok for developers to gather initial feedback on some idea before they decide to implement. Its also not absolutely necessary that implementation should be started only after design document review. The caveat here is if the proposed design is changed significantly in the process of review it will impact your implementation as well. Thus for large features where lot of design feedbacks are expected it's advisable to start your implementation once major feedbacks are captured. For example, API designs can invite lot of feedbacks. In such cases, its best to capture those feedbacks before starting the implementation cycle. But for very localized implementations not impacting other parts of the system/APIs it may be ok to provide an initial implementation(in the same PR) as a reference along with design document.

This comment has been minimized.

@donatieng

donatieng Aug 8, 2018

Member

"docucment" / "its" -> "it's" / "feedbacks" -> "feedback"

This comment has been minimized.

@donatieng

donatieng Aug 8, 2018

Member

Is it a summary? It feels a bit redundant with what's explained in the paragraph starting line 4. Might be worth breaking this down in bullet points (here are the steps).

- [Custom Headings Here](#custom-headings-here)

### Revision history
1.0 - A brief description for this version, e.g. Initial revision - Author name - Date

This comment has been minimized.

@donatieng

donatieng Aug 8, 2018

Member

If we keep a revision number (as opposed to using git) we need to agree on what it should be. Maybe it's more appropriate to say: "This document's revision addresses Mbed OS 5.10 onwards"? That way it's more understandable to see what versions of the OS this document addresses.

@SenRamakri SenRamakri force-pushed the SenRamakri:sen_MbedOSDesignProcess branch from 332b7c6 to 196094d Aug 8, 2018

@SenRamakri

This comment has been minimized.

Contributor

SenRamakri commented Aug 8, 2018

@bulislaw - Good point about the https://os.mbed.com/docs/v5.9/reference/software-design.html. I'll get this reviewed from Docs team and also add docs in Handbook to refer this process. I still think process README itself still belongs here, but will add some description in Handbook and create a link to here.

@SenRamakri

This comment has been minimized.

Contributor

SenRamakri commented Aug 8, 2018

@bulislaw @donatieng - Thanks for your detailed reviews and please see my replies above. And I have put in fixes for all other comments.

@bulislaw - I have also removed some redundancy in descriptions in README as you pointed out. And I also think its better to have revision history in the beginning so that people can see whats changed between versions and its relatively smaller section as well. I have added new directory structure under design-documents to make it better organized.

@donatieng - Good point about mentioning the Mbed-OS version in Revision section. I have added a comment to capture your feedback, please take a look on that as well.

@SenRamakri

This comment has been minimized.

Contributor

SenRamakri commented Aug 8, 2018

@AnotherButler - Can you please review this and probably copy edit for consistency?

@cmonr

This comment has been minimized.

Contributor

cmonr commented Aug 24, 2018

@ARMmbed/mbed-os-core @ARMmbed/mbed-os-docs @sg-@sam-taylor-arm @neilwjackson
@AnotherButler @ChiefBureaucraticOfficer @sreekan-a

This is a reminder that a PR is still waiting to be reviewed by you.

donatieng added a commit to donatieng/mbed-os that referenced this pull request Aug 24, 2018

donatieng added a commit to donatieng/mbed-os that referenced this pull request Aug 24, 2018

@0xc0170

This comment has been minimized.

Member

0xc0170 commented Aug 24, 2018

@AnotherButler happy with PR (approve or request changes) ?

AnotherButler added some commits Aug 24, 2018

Copy edit design-template.md
Copy edit file for consistency, grammar, spelling and voice.
Edit example_feature_design.md
Edit template for formatting and major typos.
@ChiefBureaucraticOfficer

This comment has been minimized.

ChiefBureaucraticOfficer commented Aug 27, 2018

@cmonr - Looks good to me.

@cmonr cmonr added the risk: A label Aug 27, 2018

@0xc0170 0xc0170 added needs: CI and removed needs: review labels Aug 29, 2018

@0xc0170

This comment has been minimized.

Member

0xc0170 commented Aug 29, 2018

As this received already few approvals (internal reviews already done), entering CI stage

@0xc0170

This comment has been minimized.

Member

0xc0170 commented Aug 29, 2018

/morph build

@mbed-ci

This comment has been minimized.

mbed-ci commented Aug 29, 2018

@cmonr

This comment has been minimized.

Contributor

cmonr commented Aug 29, 2018

/morph build

@cmonr cmonr added risk: G and removed risk: A labels Aug 29, 2018

@mbed-ci

This comment has been minimized.

mbed-ci commented Aug 29, 2018

Build : SUCCESS

Build number : 2953
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/7561/

Triggering tests

/morph test
/morph export-build
/morph mbed2-build

@mbed-ci

This comment has been minimized.

@cmonr

This comment has been minimized.

Contributor

cmonr commented Aug 29, 2018

Reshuffling the Integration Test queue. Will restart shortly.

@cmonr

This comment has been minimized.

Contributor

cmonr commented Sep 1, 2018

/morph test

@mbed-ci

This comment has been minimized.

@0xc0170 0xc0170 added ready for merge and removed needs: CI labels Sep 1, 2018

@0xc0170 0xc0170 merged commit 864332f into ARMmbed:master Sep 1, 2018

14 checks passed

ci-morph-build build completed
Details
ci-morph-exporter build completed
Details
ci-morph-mbed2-build build completed
Details
ci-morph-test test completed , RTOS ROM(+0.0%) RAM(+0.0%)
Details
continuous-integration/jenkins/pr-head This commit looks good
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
jenkins-ci/cloud_client_smoke_test Test job was successful
Details
travis-ci/astyle Passed, 587 files
Details
travis-ci/docs Local docs testing has passed
Details
travis-ci/events Passed, runtime is 9103 cycles (-101 cycles)
Details
travis-ci/gitattributestest Local gitattributestest testing has passed
Details
travis-ci/licence_check Local licence_check testing has passed
Details
travis-ci/littlefs Passed, code size is 8372B
Details
travis-ci/tools-py2.7 Local tools-py2.7 testing has passed
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment