Merge remote-tracking branch 'boschglobal/master' into iox-eclipse-ic…

…eoryx#337-deprecate-posix-timer

Signed-off-by: Sankara Narayanan Chandrasekar (RBEI/EMT2) <Sankara.Narayanan@in.bosch.com>

.clang-tidy

@@ -1,4 +1,4 @@
-Checks: '-*,readability-*,-readability-named-parameter,-readability-avoid-const-params-in-decls,-readability-else-after-return,performance-*,hicpp-*,-hicpp-named-parameter,-hicpp-avoid-c-arrays,cppcoreguidelines-*,-hicpp-no-array-decay,-hicpp-signed-bitwise,-hicpp-vararg,-cppcoreguidelines-avoid-c-arrays,-cppcoreguidelines-pro-bounds-constant-array-index,-cppcoreguidelines-pro-bounds-array-to-pointer-decay,-cppcoreguidelines-pro-type-vararg,concurrency-*,clang-analyzer-*,cert-*,bugprone-*'
+Checks: '-*,readability-*,-readability-named-parameter,-readability-avoid-const-params-in-decls,-readability-else-after-return,performance-*,-readability-redundant-access-specifiers,hicpp-*,-hicpp-named-parameter,-hicpp-avoid-c-arrays,cppcoreguidelines-*,-hicpp-no-array-decay,-hicpp-signed-bitwise,-hicpp-vararg,-cppcoreguidelines-avoid-c-arrays,-cppcoreguidelines-pro-bounds-constant-array-index,-cppcoreguidelines-pro-bounds-array-to-pointer-decay,-cppcoreguidelines-pro-type-vararg,concurrency-*,clang-analyzer-*,cert-*,bugprone-*'
 CheckOptions:
   - { key: readability-identifier-naming.ClassCase,               value: CamelCase }
   - { key: readability-identifier-naming.EnumCase,                value: CamelCase }

.github/workflows/axivion.yml

@@ -0,0 +1,24 @@
+name: Axivion
+
+on:
+  push:
+    branches: [ master ]
+
+jobs:
+  axivion:
+    runs-on: ubuntu-18.04
+
+    steps:
+      - name : Checkout
+        uses: actions/checkout@v2
+
+      - name: Trigger pipeline
+        env:
+          AXIVION_TRIGGER_TOKEN: ${{ secrets.AXIVION_TRIGGER_TOKEN }}
+          AXIVION_READ_API_TOKEN: ${{ secrets.AXIVION_READ_API_TOKEN }}
+        run: |
+          cd $GITHUB_WORKSPACE
+          pip3 install requests
+          PIPELINE_ID="$(./tools/axivion/trigger_pipeline.py)"
+          ./tools/axivion/wait_for_pipeline.py "${PIPELINE_ID}"
+

.gitignore

@@ -11,5 +11,6 @@ clangd/
 */doc/xml/
 site/
 doc/website/API-reference/
+tools/website/generated/
 *.project
 __pycache__

CHANGELOG.md

@@ -1,8 +1,8 @@
 # Change Log
 
-## [v1.0.0](https://github.com/eclipse-iceoryx/iceoryx/tree/v1.0.0) (2021-04-30)
+## [v1.0.0](https://github.com/eclipse-iceoryx/iceoryx/tree/v1.0.0) (2021-04-15)
 
-[Full Changelog](https://github.com/eclipse-iceoryx/iceoryx/compare/v0.90.0...v1.0.0)
+[Full Changelog](https://github.com/eclipse-iceoryx/iceoryx/compare/v0.90.7...v1.0.0)
 
 Description:
 This is the first major release for Eclipse iceoryx. That means it is the first release with long-term support and the adopters of iceoryx can rely on a stable API. The release called Almond allows for true zero-copy inter-process-communication on Linux, QNX and MacOS and provides C and modern C++ user APIs. This release is supported until 2022-04-01.

CONTRIBUTING.md

@@ -53,9 +53,37 @@ Please make sure you have:
 3. All branches have the following naming format: `iox-#[issue]-branch-name` e.g. `iox-#123-super-duper-feature`
 4. All commits have the following naming format: `iox-#[issue] commit message` e.g. `iox-#123 implemented super-duper feature`
 5. All commits have been signed with `git commit -s`
-6. You open your pull request towards the base branch `staging`
+6. You open your pull request towards the base branch `master`
 7. Link the pull request to the according Github issue and set the label accordingly
 
+## Branching strategy
+
+`master`
+
+* Main development branch
+* Open for external contributions
+
+`release_x.y`
+
+* Branch for stablising a certain release
+* Write access limited to maintainers
+* Fine-tuning of external contribution e.g. running Axivion SCA
+* Finish any missing implementations regarding the quality levels
+
+As depicted below, after the release branch has been created the stabilisation phase will begin. After finishing the release, a git tag will be created to point to `HEAD` of the release branch. Follow-up releases will be branched off from the git tag.
+
+```
+o---o---o---o---o  master
+     \
+      \      v1.0.0      v1.0.1
+       \        |           |
+        o---o---o---o---o---o---o  release_1.0
+                         \
+                          \      v1.1.0
+                           \        |
+                            o---o---o  release_1.1
+```
+
 ## Coding style
 
 We love the [C++ core guidelines](http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines). If in doubt please try
@@ -101,11 +129,13 @@ information about logging and error handling.
 Please use [doxygen](http://www.doxygen.nl/) to document your code.
 
 The following doxygen comments are required for public API headers:
+
 ```cpp
     /// @brief short description
     /// @param[in] / [out] / [in,out] name description
     /// @return description
 ```
+
 A good example for code formatting and doxygen structure is at [swe_docu_guidelines.md (WIP)](./doc/aspice_swe3_4/swe_docu_guidelines.md)
 
 ## Folder structure
@@ -128,9 +158,10 @@ All new code should follow the folder structure.
 
 1. Add the example in the ["List of all examples"](./iceoryx_examples/README.md)
 2. Create a new file in `doc/website/getting-started/examples/foobar.md`. This file shall only set the title and include the readme from `./iceoryx_examples/foobar/README.md`
-3. Add the example folder name into the `EXAMPLES=${EXAMPLES} ...` array in `./tools/iceoryx_build_test.sh`
-4. Add an `add_subdirectory` directive into `iceoryx_meta/CMakeLists.txt` in the `if(EXAMPLES)` section.
+3. Add an `add_subdirectory` directive into `iceoryx_meta/CMakeLists.txt` in the `if(EXAMPLES)` section.
+4. Consider using [geoffrey](https://github.com/elBoberido/geoffrey#geoffrey---syncs-source-code-to-markdown-code-blocks) for syncing code in code blocks with the respective source files
 5. Add integration test for example
+6. [Record an asciicast](./tools/website/how-to-record-asciicast.md) and embed image link
 
 ## Testing
 
@@ -152,6 +183,7 @@ Integration tests are composition of more than one class and test their interact
 
 To ensure that the provided testcode covers the productive code you can do a coverage scan with gcov. The reporting is done with lcov and htmlgen.
 You will need to install the following packages:
+
 ```bash
 sudo apt install lcov
 ```
@@ -161,15 +193,19 @@ The coverage scan applies to Quality level 3 and partly level 2 with branch cove
 
 For having a coverage report iceoryx needs to be compiled with coverage flags and the tests needs to be executed.
 You can do this with one command in iceroyx folder like this:
+
 ```bash
 ./tools/iceoryx_build_test.sh clean build-all -c <testlevel>
 ```
+
 Optionally you can use build-all option to get coverage for extensions like DDS or C-Binding.
 The -c flag indicates that you want to have a coverage report and you can pass there the needed testlevel. Per default the testlevel is set to 'all'.
 example:
+
 ```bash
 ./tools/iceoryx_build_test.sh debug build-all -c unit
 ```
+
 **NOTE**
 Iceoryx needs to be built as static library for working with gcov flags. The script does it automatically.
 
@@ -178,6 +214,7 @@ The flag `-c unit` is for having only reports for unit-tests. In the script `too
 All reports are stored locally in build/lcov as html report (index.html). In Github, we are using [codecov](https://about.codecov.io) for a general reporting of the code coverage.
 Codecov gives a brief overview of the code coverage and also indicates in Pull-Requests if newly added code is not covered by tests.
 If you want to download the detailed html reports from the Pull-Requests or master build you can do it by the following way:
+
 1. Open the "Checks" view in the PR
 2. Open the "Details" link for the check `iceoryx-coverage-doxygen-ubuntu` in `Test Coverage + Doxygen Documentation`
 3. On the right side you find a menu button `Artifacts` which shows `lcov-report` as download link
@@ -186,43 +223,52 @@ If you want to download the detailed html reports from the Pull-Requests or mast
 
 ### Safety & security
 
-We aim for [ASIL-D](https://en.wikipedia.org/wiki/Automotive_Safety_Integrity_Level#ASIL_D) compliance. The
-[ISO26262](https://en.wikipedia.org/wiki/ISO_26262) is also a good read-up if you want to learn more about automotive
-safety. A nice introduction [video](https://www.youtube.com/watch?v=F4GzsA00s5I) was presented on CppCon 2019.
+The iceoryx maintainers aim for [ASIL-D](https://en.wikipedia.org/wiki/Automotive_Safety_Integrity_Level#ASIL_D)
+compliance. The [ISO26262](https://en.wikipedia.org/wiki/ISO_26262) is also a good read-up if you want to learn more
+about automotive safety. A nice introduction [video](https://www.youtube.com/watch?v=F4GzsA00s5I) was presented on
+CppCon 2019.
 
 If you want to report a vulnerability, please use the [Eclipse process](https://www.eclipse.org/security/).
 
-We have a [partnership](https://www.perforce.com/blog/qac/why-eclipse-iceoryx-uses-helix-qac) with [Perforce](https://www.perforce.com) and use
-[Helix QAC++ 2019.2](https://www.perforce.com/products/helix-qac) to perform a static-code analysis.
+#### Static code analysis
+
+The iceoryx maintainers have a partnership with [Axivion](https://www.axivion.com/en/) and use their
+[Axivion Suite](https://www.axivion.com/en/products/static-code-analysis/) to run a static-code analysis.
 
 Github [labels](https://github.com/eclipse-iceoryx/iceoryx/labels) are used to group issues into the rulesets:
 
-| Ruleset name | Github issue label |
-|---|---|
-| [MISRA](https://www.misra.org.uk/) C++ 2008 | MISRA |
-| [Adaptive AUTOSAR](https://www.autosar.org/fileadmin/user_upload/standards/adaptive/17-03/AUTOSAR_RS_CPP14Guidelines.pdf) C++14 | AUTOSAR |
-| [SEI CERT C++](https://wiki.sei.cmu.edu/confluence/pages/viewpage.action?pageId=88046682) 2016 Coding Standard | CERT |
+| Ruleset name | Github issue label | Priority |
+|---|---|---|
+| [Adaptive AUTOSAR](https://www.autosar.org/fileadmin/user_upload/standards/adaptive/17-03/AUTOSAR_RS_CPP14Guidelines.pdf) C++14 | AUTOSAR | :star::star::star: |
+| [SEI CERT C++](https://wiki.sei.cmu.edu/confluence/pages/viewpage.action?pageId=88046682) 2016 Coding Standard | CERT | :star::star: |
+| [MISRA](https://www.misra.org.uk/) C++ 2008 | MISRA | :star: |
+
+The enabled rules can be found [here](./tools/axivion/axivion_config.json). It is possible that not the whole codebase
+follows these rules, things are work in progress. But this is where we want to go.
 
 If one of the rules is not followed, a rationale is added in the following manner:
 
 With a comment in the same line:
+
 ```cpp
     *mynullptr = foo; // PRQA S 4242 # Short description why
 ```
+
 With a comment one line above (with the number after the warning number, next ’n’ lines are inclusive)
+
 ```cpp
     // PRQA S 4242 1 # Short description why
     *mynullptr = foo;
 ```
-Don't be afraid if you don't have Helix QAC++ available. As we want to make it easy for developers to contribute,
-please use the ``staging`` branch and we'll run the QAC++ scan and get back to you.
 
-Results will be available on this [Helix QAC dashboard](https://qaverify.programmingresearch.com/). Please contact one
-of the maintainers, if you're interested in getting access.
+Scan results of the `master` branch are available on a [Axivion dashboard](https://iceoryx-axivion.apex.ai/). Please
+contact one of the maintainers, if you're interested in getting access.
+
+Don't be afraid if you don't have Axivion available. As we want to make it easy for developers to contribute,
+please raise a pull request and one of the maintainers will provided you access to the [dashboard](https://iceoryx-axivion.apex.ai/).
 
-It is possible that not the whole codebase follows these rules, things are work in progress. But this is where we want
-go. As of now we don't have any continuos integration checks implemented but will rely on reviews during the pull
-requests. We're planning to introduce continuos integration checks in the near future.
+As an alternative it is also possible to use Perforce's
+[Helix QAC++ 2019.2](https://www.perforce.com/products/helix-qac) to perform a static-code analysis.
 
 ### Header
 
@@ -245,6 +291,7 @@ Each source file needs to have this header:
     //
     // SPDX-License-Identifier: Apache-2.0
 ```
+
 Note: The date is either a year or a range of years with the first and last years of the range separated by a dash. For example: "2004" (initial and last contribution in the same year) or "2000 - 2004". The first year is when the contents of the file were first created and the last year is when the contents were last modified. The years of contribution should be ordered in chronological order, thus the last date in the list should be the year of the most recent contribution. If there is a gap between contributions of one or more calendar years, use a comma to separate the disconnected contribution periods (e.g. "2000 - 2004, 2006").
 
 Example:
@@ -267,46 +314,62 @@ Example:
     //
     // SPDX-License-Identifier: Apache-2.0
 ```
+
 **_NOTE:_**  For scripts or CMake files you can use the respective comment syntax like `#` for the header.
-## Quality levels
 
-CMake targets can be developed according to different quality levels. Despite developing some of our targets according
-to automotive standards like ISO26262, the code base standalone does NOT legitimize the usage in a safety critical
-system. All requirements of a lower quality level are included in higher quality levels e.g. quality level 4 is
-included in quality level 3.
+## Quality levels
 
-Also see [ROS quality levels](https://github.com/ros-infrastructure/rep/blob/master/rep-2004.rst).
+The CMake targets are developed according to the
+[ROS quality levels](https://github.com/ros-infrastructure/rep/blob/master/rep-2004.rst).
+Despite developing some of the targets according to automotive standards like ISO26262, the code base standalone
+does NOT legitimize the usage in a safety-critical system. All requirements of a lower quality level are included in
+higher quality levels e.g. quality level 4 is included in quality level 3.
 
 ### Quality level 5
 
 This quality level is the default quality level. It is meant for examples and helper tools.
 
-* Reviewed by two approver
-* License and copyright statement available
-* No version policy required
-* No unit tests required
+* Derived from [ROS quality level 5](https://www.ros.org/reps/rep-2004.html#quality-level-5)
+  * Reviewed by two approver
+  * No compiler warnings
+  * License and copyright statement available
+  * No version policy required
+  * No unit tests required
 
 ### Quality level 4
 
-This quality level is meant for all targets that need tier 1 support in ROS2.
-
-* Basic unit tests are available
+* Derived from [ROS quality level 4](https://www.ros.org/reps/rep-2004.html#quality-level-4)
+  * Basic unit tests are required
+  * Builds and runs on Windows, MacOS, Linux and QNX
 
 ### Quality level 3
 
-* No compiler warnings
-* Doxygen and documentation available
-* Test specification available
-* Version policy required
-* Level 8 and 9 warnings in Helix QAC addressed
+* Derived from [ROS quality level 3](https://www.ros.org/reps/rep-2004.html#quality-level-3)
+  * Doxygen and documentation required
+  * Test specification required
+  * Version policy required
 
 ### Quality level 2
 
-* Unit tests have full statement and branch coverage
+This quality level is meant for all targets that need tier 1 support in ROS 2.
+
+* Derived from [ROS quality level 2](https://www.ros.org/reps/rep-2004.html#quality-level-2)
+  * Must have a [quality declaration document](https://www.ros.org/reps/rep-2004.html#quality-declaration-template)
 
 ### Quality level 1
 
-* Warnings in Helix QAC addressed
+* Derived from [ROS quality level 1](https://www.ros.org/reps/rep-2004.html#quality-level-1)
+  * Version policy for stable API and ABI required
+  * [ASPICE](https://beza1e1.tuxen.de/aspice.html) SWE.6 tests available
+  * Performance tests and regression policy required
+  * Static code analysis warnings in Axivion addressed
+  * Enforcing the code style is required
+  * Unit tests have full statement and branch coverage
+
+### Quality level 1+
+
+This quality level goes beyond the ROS quality levels and contains extensions.
+
 * Code coverage according to [MC/DC](https://en.wikipedia.org/wiki/Modified_condition/decision_coverage) available
 
 ## Training material recommended for contributors

GOVERNANCE.md

@@ -9,17 +9,11 @@ An up to date list of the maintainers can be found at the [Eclipse project page]
 
 ## Bi-weekly meetup
 
-Bi-weekly every first and third Thursday for 1 hour. Everyone is welcome to join.
+The developer meetup is held bi-weekly on Thursday from 17:00 - 18:00 CET. Everyone is welcome to join.
 
 You can join by using this Zoom link: https://eclipse.zoom.us/j/95918504483?pwd=RWM5Y1pkeStKVDZsU09EY1hnclREUT09
 
-```
-08:00 PST (GMT - 8)
-16:00 GMT
-17:00 CET (GMT + 1)
-21:30 IST (GMT + 5.5)
-00:00 CST (GMT + 8)
-```
+For a calendar event, you can subscribe to the [ROS calendar](https://calendar.google.com/calendar/u/0/embed?src=agf3kajirket8khktupm9go748@group.calendar.google.com&ctz=America/Los_Angeles).
 
 ### Topics