Iox #743 Backport: Fix website generation and typos for v1.x release

[mossmaurice]

Pre-Review Checklist for the PR Author

1. Code follows the coding style of CONTRIBUTING.md
2. Tests follow the best practice for testing
3. Branch follows the naming format (iox-#123-this-is-a-branch)
4. Commits messages are according to this guideline
   • Commit messages have the issue ID (iox-#123 commit text)
   • Commit messages are signed (git commit -s)
   • Commit author matches Eclipse Contributor Agreement (and ECA is signed)
5. Update the PR title
   • Follow the same conventions as for commit messages
   • Link to the relevant issue
6. Relevant issues are linked
7. Add sensible notes for the reviewer
8. All checks have passed (except task-list-completed)
9. Assign PR to reviewer

Notes for Reviewer

• Backport changes from Iox #743 Fix website generation and typos #746 for upcoming v1.x

Checklist for the PR Reviewer

• Commits are properly organized and messages are according to the guideline
• Code according to our coding style and naming conventions
• Unit tests have been written for new behavior
• Public API changes are documented via doxygen
• Copyright owner are updated in the changed files
• PR title describes the changes

Post-review Checklist for the PR Author

1. All open points are addressed and tracked via issues

References

• Closes partly Improve documentation and website for v2.0 #743

[codecov]

Codecov Report

Merging #756 (b0a0338) into release_1.0 (4ba77c5) will increase coverage by 0.10%.
The diff coverage is 66.56%.

@@               Coverage Diff               @@
##           release_1.0     #756      +/-   ##
===============================================
+ Coverage        73.87%   73.97%   +0.10%     
===============================================
  Files              318      319       +1     
  Lines            11077    11425     +348     
  Branches          1950     1972      +22     
===============================================
+ Hits              8183     8452     +269     
- Misses            2130     2196      +66     
- Partials           764      777      +13     

Flag	Coverage Δ
unittests	72.77% <64.64%> (+0.05%)	⬆️
unittests_timing	30.50% <15.84%> (-1.18%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
...ude/iceoryx_binding_c/internal/cpp2c_publisher.hpp	100.00% <ø> (ø)
...de/iceoryx_binding_c/internal/cpp2c_subscriber.hpp	100.00% <ø> (ø)
iceoryx_binding_c/source/c_runtime.cpp	52.94% <0.00%> (-7.06%)	⬇️
...ceoryx_dds/include/iceoryx_dds/dds/data_writer.hpp	0.00% <ø> (ø)
...nclude/iceoryx_dds/internal/gateway/dds_to_iox.inl	44.18% <0.00%> (-7.17%)	⬇️
...nclude/iceoryx_dds/internal/gateway/iox_to_dds.inl	55.73% <0.00%> (-7.23%)	⬇️
...dds/source/iceoryx_dds/dds/cyclone_data_writer.cpp	0.00% <0.00%> (ø)
...ude/iceoryx_posh/internal/mepoo/memory_manager.hpp	100.00% <ø> (ø)
...clude/iceoryx_posh/internal/mepoo/shared_chunk.hpp	100.00% <ø> (ø)
...nternal/popo/building_blocks/chunk_distributor.hpp	100.00% <ø> (ø)
... and 144 more

[elBoberido]

Why not merge right away? Are you waiting for possible more fixes?

[mossmaurice]

Why not merge right away? Are you waiting for possible more fixes?

AFAIK the ROS CI automatically checks and requires that the v1.0.0 tag points to the latest commit on the release_1.0 branch.

@dkroenke Correct or can we merge backports to release_1.0?

[dkroenke]

Why not merge right away? Are you waiting for possible more fixes?

AFAIK the ROS CI automatically checks and requires that the v1.0.0 tag points to the latest commit on the release_1.0 branch.

@dkroenke Correct or can we merge backports to release_1.0?

If we do intermediate merges, the ROS buildfarm will notice that and ROS will request a new release from us because they cannot oversee if the merge may breaks the API/ABI, therefore i recommend to do coordinated merges to ensure that a new iceoryx release on ROS is build afterwards.

[elBoberido]

@dkroenke there must be a different solution for this. We cannot pile up the PRs for the release branch and merge all at once. This is a horrible workflow and counteracts the purpose of a release branch where fixes are back-ported and releases are done on demand

[elfenpiff]

Let's say I do not believe you that the path is now correct. How can I verify the correctness of those relative paths as a reviewer?
Why is it relative at all? Couldn't we use absolute paths here?

[mossmaurice]

See answer in the original pull request. The sanity check should be sufficient? I'm afraid absolute paths are not possible IIRC.