Versions Compared

Old Version 191

changes.mady.by.user Thomas Kulik

Saved on

compared with

New Version 192

changes.mady.by.user Thomas Kulik

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Create new the using gerritsource/initial=', target/new={releasename}' n/a follow instructions Open https/r/admin/repos/doc,branches
  • Use [CREATE NEW] function on the top right corner
  • Set 'Branch name' to the name of the upcoming release (e.g. 'istanbul')
  • Set 'Initial revision' to 'master'
  • Use [CREATE] to create the new branch

    • Note: You are not allowed to delete a branch. If you need to (maybe due to a typo in the process of creation) you have to raise a ticket at the LF IT Support.

    (warning) IMPORTANT: To trigger the documentation build in ReadTheDocs, you must change at least one of the ReStructuredText files (.rst) in the new branch. Only branching the repository does not trigger the RTD doc build process. Consequently the '{releasename}' version of documentation is missing in RTD.

    OPEN: Currently we are branching the repository early - and consequently have to cherry-pick the changes (done in 'master') for '{releasename}'. Check if it is ok to branch later (after changing the majority of files). So we can reduce cherry-pick efforts.

    Clone 'master' branch of 'doc' repository to your local development environment

    RELEASE: main + maintenance all Please use the command below.

    git clone -b master --recurse-submodules ssh://<username>@gerrit.onap.org:29418/doc

    Now you can start to modify files in the 'master' branch.

    Update architecture description'; then cherry-pick for '{releasename}guides/onap-developer/architecture/onap-architecture.rst This file contains a description of the ONAP architecture authored together with the architecture subcommittee. Update the file accordingly for the new release and cherry-pick the change for '{releasename}'.

    CONTACT: Chaker Al-Hakim  Byung-Woo Jun 

    EXAMPLE: 'onap-architecture.rst' for 'master' branch

    › View in RTD

    OPEN: Activity for the Architecture Subcommittee (change rst file and propose a patch)? Add task/milestone to the release process? To be aligned with marketing department?

    Update references in 'ONAP Components and Functionalities' section

    RELEASE: main + maintenance (opt)

    BRANCH: 'master'; then cherry-pick for '{releasename}'

    FILE: doc/docs/guides/onap-developer/developing/index.rst

    DESCR: This file contains references to the detailed documentation of ONAP projects, components and functionalities. Important to know: Beginning with the 'jakarta' release a project/repository contributing to the documentation of the release needs to be a) actively maintained and b) create a branch for the new release. Otherwise the project/repository will not be included. Update the file accordingly for the new release and cherry-pick the change for '{releasename}'.

    EXAMPLE: 'index.rst' for 'master' branch

    › View in RTD

    Update sphinx build configuration file 'conf.py'

    confpyThe Sphinx build configuration file 'conf.py' contains configuration needed to customize Sphinx input and output behavior. Please follow the instructions below.
    1. Set 'intersphinx_mapping' for projects/repositories participating to the release.
    2. Remove 'intersphinx_mapping' for projects/repositories not participating to the release.

    Note: Beginning with the 'jakarta' release a project/repository contributing to the documentation of the release needs to be a) actively maintained and b) create a branch for the new release. Otherwise the project/repository will not be included. Intersphinx mapping sections for those projects/repositories are removed from 'conf.py'.

    EXAMPLE: 'conf.py' for 'master' branch

    OPEN: Add reliable source for the info if a project has/hasn't branched.

    OPEN: Include changes/actions required because we have introduced constraints-files.

    OPEN: Update to 'conf.yaml' required after branching the repo?

    OPEN: Add note to keep files/content  in sync: conf.py / list of project specific relese notes / references in 'ONAP Components and Functionalities' section

    Update overview description

    RELEASE: main + maintenance (opt)

    BRANCH: 'master'; then cherry-pick for '{releasename}'

    FILE: doc/docs/guides/overview/overview.rst

    DESCR: This file contains an overview of ONAP authored together with the architecture subcommittee. Update the file accordingly for the new release and cherry-pick the change for '{releasename}'.

    CONTACT: Chaker Al-Hakim  Byung-Woo Jun 

    EXAMPLE: 'overview.rst' for 'master' branch

    › View in RTD

    OPEN: Activity for the Architecture Subcommittee (change rst file and propose a patch)? Add task/milestone to the release process? To be aligned with marketing department?

    Update interactive ONAP architecture overview diagram and related files

    RELEASE: main + maintenance (opt)

    BRANCH: 'master'

    FILE #1: doc/docs/guides/onap-developer/architecture/media/onap-architecture-overview-interactive.svg

    FILE #2: doc/docs/guides/onap-developer/architecture/onap-architecture.rst

    CONTACT: Chaker Al-Hakim Byung-Woo Jun  Thomas Kulik

    DESCR: Please follow the instructions below.

    1. Optional: Open the file 'onap-architecture-overview-labels-and-links.xlsx', check if links are reachable (to be detailed)
    2. The interactive ONAP architecture overview (svg format, maintained by the 'doc' project team) needs to be aligned with the official ONAP architecture diagram maintained by the Architecture Subcommittee (e.g. Istanbul-R9 Architecture Diagram). Open the file 'onap-architecture-overview-interactive.svg' in Inkscape and change the architecture building blocks accordingly.
    3. In the 'Objects' window find the 'releaseinfo.link' object. Make it visible by clicking on the 'closed eye' symbol to change it to an 'open eye' symbol. Now the release info should be visible on the overview.
    4. Click on tab 'Object attributes' and check/update the content of the field 'Href:' (the link must point to 'latest').
    5. Update the content of the field 'Title:' to show the new release number and name (e.g. 'ONAP Release 9 »Istanbul«').
    6. In the 'Objects' window find the 'releaseinfo.link' object. Make it invisible again by clicking on the 'open eye' symbol to change it to a 'closed eye' symbol. Now the release info should be no longer visible on the overview.
    7. Save the file.
    8. Save the file a second time, but with a new filename. Use 'onap-architecture-overview-interactive-path.svg'.
    9. Then select all (warning) elements in the map and use the Inkscape function 'Path → Object to Path' to convert all elements to pathes. Read more about this in the onap-architecture-overview-notes.txt . Save the overview map, close Inkscape (and remember to do no (warning) further changes to this 'pathed' version of the overview).
    10. Info: In 'doc/docs/guides/onap-developer/architecture/onap-architecture.rst' you find a '.. raw:: html' section which contains the filename of the interactive ONAP architecture overview. You must use the filename of the 'pathed' version ('onap-architecture-overview-interactive-path.svg') here!

    EXAMPLE: 'onap-architecture.rst' for 'master' branch

    › View in RTD

    OPEN: Describe how to update and test links in xls and svg
    TITLE

    P01: Create documentation for an ONAP release (doc project team)

    SUBJECT

    Procedure #01 describes the required tasks which are performed by the ONAP 'doc' project team and supplying parties to create the release-specific documentation for an ONAP main and maintenance release. Although this procedure targets the 'doc' project, it can give general advice for all other ONAP projects to create their release specific documentation.

    Read "P02: Create documentation for an ONAP release (ONAP project teams)" if you need to create documentation for an ONAP project other than 'doc'.

    TARGET AUDIENCE
    		ONAP 'doc' project team: Maintainers of the 'doc' repository
    Supplying parties: Architecture Subcommittee, ONAP TSC Chair
    RELEASE RELEVANCE
    		10.x.x 'Jakarta' – 8.x.x 'Honolulu'
    TABLE OF CONTENTS

    Table of Contents
    maxLevel3
    minLevel3
    styledisk

    AUTHOR(S)

    Thomas Kulik

    REVIEWER(S)
    		use @notation
    NOTES

    Not every step within a single task is listed. For example, common tasks like 'git' operations (e.g. add, remove, commit, review) are not included. Jira or Gerrit activities (e.g. review, submit, cherry-pick) related to file changes are also not listed.

    A development environment to write and preview reStructuredText is prerequisite, also some knowledge how to use Inkscape is required.

    The following tasks may have a different relevance depending on the type of release (main, maintenance) you are working on. Optional tasks for a maintenance release marked as 'maintenance (opt)'. They are expected to be performed only if you need to fix issues or you have to incorporate smaller changes.

    The placeholder '{releasename}' needs to be substituted by the name of the new release, e.g. 'istanbul' or 'jakarta'.


    PREPARATION I

    01

    Create a new Jira tasks and use the ID for all upcoming changes

    RELEASE: main + maintenance

    BRANCH: not applicable

    FILE: n/a

    DESCR: Please follow the instructions below.

    1. Open https://https://jira.onap.org/
    2. Create a new task for the 'doc' project and name it e.g. "Create docs for '{releasename}' {main|maintenance} release". Assign the release '{releasename}' to it. The ID is required for submitting all related changes in gerrit. The format to be used in gerrit is 'Issue-ID: DOC-nnn'.
    NEW POSITION

    Clone 'master'

    02

    branch of

    'doc' repository

    to your local development environment

    RELEASE: main + maintenance

    BRANCH:

    'master

    '

    FILE:

    all

    DESCR: Please

    use the

    command below.

    git clone -b master --recurse-submodules ssh://<username>@gerrit.onap.org

    03

    :29418/doc

    Now you can start to modify files in the 'master' branch.


    UPDATES IN MASTER BRANCH

    04

    Update 'doc' project release notes

    RELEASE: main + maintenance (opt)

    BRANCH: 'master'

    FILE: doc/docs/release-notes.rst

    DESCR: The file contains a description of the latest changes in the 'doc' project. Update it accordingly for the new release.

    EXAMPLE: 'release-notes.rst' for 'master' branch

    › View in RTD

    OPEN: check all project specific release notes (updated? release number/release name correct? ...)

    OPEN: Evaluate if we can/should have only 'placeholder' files in the 'master' branch. This may avoid confusion in case people are looking to 'master' and seeing release specific content (e.g. related to 'istanbul'). Or should we remove - at least - release names in the RTD navigation (column on the left)?

    05

    Update composite release note

    RELEASE: main + maintenance (opt)

    BRANCH: 'master'

    FILE:

     doc/docs/release/index.rst

    DESCR:

    This file contains a brief overview about the advantages and latest developments related to the new release. It is also known as the 'composite' release note. The text is authored by the 'doc' team together with the ONAP TSC chair. We are using information from the 'Release Key Updates' table which is maintained by the projects during the release process (e.g. 'Release Key Updates' for the 'istanbul' release). The content is provided in text form and has to be converted to reStructuredText format manually. Update the file accordingly - especially the release date.

    CONTACT: Catherine Lefevre Kenny Paul Eric Debeau

    EXAMPLE: 'index

    04

    Update 'doc' project release notes

    RELEASE: main + maintenance (opt)

    BRANCH: 'master'; then cherry-pick for '{releasename}'

    FILE: doc/docs/release-notes.rst

    DESCR: The file contains a description of the latest changes in the 'doc' project. Update it accordingly for the new release and cherry-pick the change for '{releasename}'.

    EXAMPLE: 'release-notes.rst' for 'master' branch

    › View in RTD

    OPEN: check all Add a task/milestone to the release process?

    OPEN: Describe the process of conversion to reStructuredText format. Example Source

    06

    Update list of project specific release notes

    (updated? release number/release name correct? ...)

    OPEN: Evaluate if we can/should have only 'placeholder' files in the 'master' branch. This may avoid confusion in case people are looking to 'master' and seeing release specific content (e.g. related to 'istanbul'). Or should we remove - at least - release names in the RTD navigation (column on the left)?

    RELEASE: main + maintenance (opt)

    BRANCH: 'master'

    FILE: doc/docs/release/releaserepos.rst

    DESCR: This file contains a table of contents (TOC) for project specific release notes. Important to know: Beginning with the 'jakarta' release a project/repository contributing to the documentation of the release needs to be a) actively maintained and b) create a branch for the new release. Otherwise the project/repository will not be included. Update the file accordingly for the new release.

    EXAMPLE: 'releaserepos.rst' for 'master' branch

    › View in RTD

    OPEN: Add reliable source for 'release participating projects/repositories' and their 'maintenance-state' and - in addition - those ('unmaintained') projects which are deployed 'on top' by OOM team (because the projects/repos are still required for a good reason).

    07

    Update release history in overview

    RELEASE: main + maintenance

    BRANCH: 'master'

    FILE: doc/docs/guides/overview/overview.rst

    DESCR: This file contains a table with the release history (release number, date, name). Update the file accordingly for the new release.

    EXAMPLE: 'overview

    05

    Update composite release note

    RELEASE: main + maintenance (opt)

    BRANCH: 'master'; then cherry-pick for '{releasename}'

    FILE: doc/docs/release/index.rst

    DESCR: This file contains a brief overview about the advantages and latest developments related to the new release. It is also known as the 'composite' release note. The text is authored by the 'doc' team together with the ONAP TSC chair. We are using information from the 'Release Key Updates' table which is maintained by the projects during the release process (e.g. 'Release Key Updates' for the 'istanbul' release). The content is provided in text form and has to be converted to reStructuredText format manually. Update the file accordingly - especially the release date and cherry-pick the change for '{releasename}'.

    CONTACT: Catherine Lefevre Kenny Paul Eric Debeau
    EXAMPLE: 'index.rst' for 'master' branch

    › View in RTD

    OPEN: Add a task/milestone to the release process?

    OPEN: Describe the process of conversion to reStructuredText format. Example Source

    Additional check and update by Architecture Subcommittee required?

    08

    Update architecture description

    06
    Update list of project specific release notes

    RELEASE: main + maintenance (opt)

    BRANCH: 'master'; then cherry-pick for '{releasename}'

    FILE: doc/docs/release/releaserepos/guides/onap-developer/architecture/onap-architecture.rst

    DESCR: This file contains a table of contents (TOC) for project specific release notes. Important to know: Beginning with the 'jakarta' release a project/repository contributing to the documentation of the release needs to be a) actively maintained and b) create a branch for the new release. Otherwise the project/repository will not be includeddescription of the ONAP architecture authored together with the architecture subcommittee. Update the file accordingly for the new release and cherry-pick the change for '{releasename}'..

    CONTACT: Chaker Al-Hakim  Byung-Woo Jun 

    EXAMPLE: 'releasereposonap-architecture.rst' for 'master' branch

    › View in RTD

    OPEN: Add reliable source for 'release participating projects/repositories' and their 'maintenance-state' and - in addition - those ('unmaintained') projects which are deployed 'on top' by OOM team (because the projects/repos are still required for a good reason).Activity for the Architecture Subcommittee (change rst file and propose a patch)? Add task/milestone to the release process? To be aligned with marketing department?

    09

    Update references in 'ONAP Components and Functionalities' section

    07
    Update release history in overview

    RELEASE: main + maintenance (opt)

    BRANCH: 'master'; then cherry-pick for '{releasename}'

    FILE: doc/docs/guides/overview/overviewonap-developer/developing/index.rst

    DESCR: This file contains a table with the release history (release number, date, name). Update the file accordingly for the new release and cherry-pick the change for '{releasename}'references to the detailed documentation of ONAP projects, components and functionalities. Important to know: Beginning with the 'jakarta' release a project/repository contributing to the documentation of the release needs to be a) actively maintained and b) create a branch for the new release. Otherwise the project/repository will not be included. Update the file accordingly for the new release.

    EXAMPLE: 'overviewindex.rst' for 'master' branch

    › View in RTD

    OPEN: Additional check and update by Architecture Subcommittee required?

    08
    10

    Update sphinx build configuration file 'conf.py'

    RELEASE: main + maintenance (opt)

    BRANCH: 'master

    '

    FILE: doc/docs/

    conf.py

    DESCR:

    09
    10

    The Sphinx build configuration file 'conf.py' contains configuration needed to customize Sphinx input and output behavior. Please follow the instructions below.

    1. Set 'intersphinx_mapping' for projects/repositories participating to the release.
    2. Remove 'intersphinx_mapping' for projects/repositories not participating to the release.

    Note: Beginning with the 'jakarta' release a project/repository contributing to the documentation of the release needs to be a) actively maintained and b) create a branch for the new release. Otherwise the project/repository will not be included. Intersphinx mapping sections for those projects/repositories are removed from 'conf.py'.

    EXAMPLE: 'conf.py' for 'master' branch

    OPEN: Add reliable source for the info if a project has/hasn't branched.

    OPEN: Include changes/actions required because we have introduced constraints-files.

    OPEN: Update to 'conf.yaml' required after branching the repo?

    OPEN: Add note to keep files/content  in sync: conf.py / list of project specific relese notes / references in 'ONAP Components and Functionalities' section

    NEW

    Update overview description

    RELEASE: main + maintenance (opt)

    BRANCH: 'master'

    FILE: doc/docs/guides/overview/

    overview.

    rst

    DESCR:

    NEW
    11

     This file contains an overview of ONAP authored together with the architecture subcommittee. Update the file accordingly for the new release.

    CONTACT: Chaker Al-Hakim  Byung-Woo Jun 

    EXAMPLE: 'overview.rst' for 'master' branch

    › View in RTD

    OPEN: Activity for the Architecture Subcommittee (change rst file and propose a patch)? Add task/milestone to the release process? To be aligned with marketing department?

    11

    Update interactive ONAP architecture overview diagram and related files

    RELEASE: main + maintenance (opt)

    BRANCH: 'master'

    FILE #1: doc/docs/guides/onap-developer/architecture/media/onap-architecture-overview-interactive.svg

    FILE #2: doc/docs/guides/onap-developer/architecture/onap-architecture.rst

    CONTACT: Chaker Al-Hakim Byung-Woo Jun  Thomas Kulik

    DESCR: Please follow the instructions below.

    1. Optional: Open the file 'onap-architecture-overview-labels-and-links.xlsx', check if links are reachable (to be detailed)
    2. The interactive ONAP architecture overview (svg format, maintained by the 'doc' project team) needs to be aligned with the official ONAP architecture diagram maintained by the Architecture Subcommittee (e.g. Istanbul-R9 Architecture Diagram). Open the file 'onap-architecture-overview-interactive.svg' in Inkscape and change the architecture building blocks accordingly.
    3. In the 'Objects' window find the 'releaseinfo.link' object. Make it visible by clicking on the 'closed eye' symbol to change it to an 'open eye' symbol. Now the release info should be visible on the overview.
    4. Click on tab 'Object attributes' and check/update the content of the field 'Href:' (the link must point to 'latest').
    5. Update the content of the field 'Title:' to show the new release number and name (e.g. 'ONAP Release 9 »Istanbul«').
    6. In the 'Objects' window find the 'releaseinfo.link' object. Make it invisible again by clicking on the 'open eye' symbol to change it to a 'closed eye' symbol. Now the release info should be no longer visible on the overview.
    7. Save the file.
    8. Save the file a second time, but with a new filename. Use 'onap-architecture-overview-interactive-path.svg'.
    9. Then select all (warning) elements in the map and use the Inkscape function 'Path → Object to Path' to convert all elements to pathes. Read more about this in the onap-architecture-overview-notes.txt . Save the overview map, close Inkscape (and remember to do no (warning) further changes to this 'pathed' version of the overview).
    10. Info: In 'doc/docs/guides/onap-developer/architecture/onap-architecture.rst' you find a '.. raw:: html' section which contains the filename of the interactive ONAP architecture overview. You must use the filename of the 'pathed' version ('onap-architecture-overview-interactive-path.svg') here!

    EXAMPLE: 'onap-architecture.rst' for 'master' branch

    › View in RTD

    OPEN: Describe how to update and test links in xls and svg.


    PREPARATION II

    NEW POSITION

    Create new branch of the 'doc' repository using gerrit

    RELEASE: main

    BRANCH: source/initial='master', target/new='{releasename}'

    FILE: n/a

    DESCR: Please follow the instructions below.

    1. Open https://gerrit.onap.org/r/admin/repos/doc,branches
    2. Use [CREATE NEW] function on the top right corner
    3. Set 'Branch name' to the name of the upcoming release (e.g. 'istanbul')
    4. Set 'Initial revision' to 'master'
    5. Use [CREATE] to create the new branch

    Note: You are not allowed to delete a branch. If you need to (maybe due to a typo in the process of creation) you have to raise a ticket at the LF IT Support.

    (warning) IMPORTANT: To trigger the documentation build in ReadTheDocs, you must change at least one of the ReStructuredText files (.rst) in the new branch. Only branching the repository does not trigger the RTD doc build process. Consequently the '{releasename}' version of documentation is missing in RTD.

    OPEN: Currently we are branching the repository early - and consequently have to cherry-pick the changes (done in 'master') for '{releasename}'. Check if it is ok to branch later (after changing the majority of files). So we can reduce cherry-pick efforts

    .

    12

    Clone '{releasename}' branch of 'doc' repository to your local development environment

    RELEASE: main + maintenance

    BRANCH: '{releasename}'

    FILE: all

    DESCR: Please use the command below.

    git clone --branch <newbranch> --recurse-submodules ssh://<username>@gerrit.onap.org:29418/doc

    Now you can start to modify files in the new branch.


    UPDATES IN RELEASE BRANCH

    13

    Set correct 'defaultbranch' in '.gitreview'

    RELEASE: main

    BRANCH: '{releasename}'

    FILE: doc/.gitreview

    DESCR: Add/update the 'defaultbranch' entry accordingly (e.g. 'defaultbranch=istanbul' for the 'istanbul' branch/release). This can help to avoid that changes are accidently committed or even published to a wrong branch.

    EXAMPLE: '.gitreview' for 'istanbul' release/branch

     

    14

    Update sphinx build configuration file 'conf.py'

    RELEASE: main + maintenance (opt)

    BRANCH: '{releasename}'

    FILE: doc/docs/conf.py

    DESCR: The Sphinx build configuration file 'conf.py' contains configuration needed to customize Sphinx input and output behavior. Please follow the instructions below.

    1. On top of the file, set "branch = '{releasename}'".
    2. Set 'intersphinx_mapping' for all participating projects/repositories.
    3. Update 'linkcheck_ignore' entries. Replace '/latest/' with '/<newbranch>/'.

    (warning) IMPORTANT: Not changing 'linkcheck_ignore' entries will lead into 'anchor issues' during the documentation build process.

    Note: The different 'intersphinx_mapping' sections in the 'conf.py' represent the different state of development in the ONAP projects and their repositories. We have to differentiate between:

    • Projects/repos that have created a branch for the upcoming release. That's why the entries are mapping to project documentation in the new created branch (branch = '{releasename}').
    • Projects/repos that have not created a branch for the upcoming release, but for a previous release. That's why the entries are mapping to project documentation in a previous branch (e.g. branch = 'frankfurt' or branch = 'guillin').
    • Projects/repos that have never created a branch. That's why the entries are mapping to project documentation in the 'master' branch of ONAP (branch = 'latest'). The ONAP 'master' branch is mapped to 'latest' in ReadTheDocs.

    EXAMPLE: 'conf.py' for 'istanbul' branch/release

     

    OPEN: Add reliable source for the info if a project has/hasn't branched.

    OPEN: Include changes/actions required because we have introduced constraints-files.

    OPEN: Update to 'conf.yaml' required after branching the repo?

    OPEN: There are plans for upcoming releases to include only projects/repositories which are in 'maintained' state and have created a branch for the new release.

    15

    Update interactive ONAP architecture overview diagram and related files

    RELEASE: main + maintenance (opt)

    BRANCH: '{releasename}'

    FILE #1: doc/docs/guides/onap-developer/architecture/media/onap-architecture-overview-interactive.svg

    FILE #2: doc/docs/guides/onap-developer/architecture/onap-architecture.rst

    CONTACT: Thomas Kulik

    DESCR: Please follow the instructions below.

    1. PREREQUISITE: The interactive ONAP architecture overview (svg format, maintained by the 'doc' project team) must already have been aligned to the official ONAP architecture diagram maintained by the Architecture Subcommittee (e.g. Istanbul-R9 Architecture Diagram). See above.
    2. Optional: Open the file 'onap-architecture-overview-labels-and-links.xlsx', change links to point to '{releasename}' and not 'latest'; check if links are reachable (to be detailed).
    3. Open file 'onap-architecture-overview-interactive.svg' in Inkscape
    4. In the 'Objects' window find the 'releaseinfo.link' object. Make it visible by clicking on the 'closed eye' symbol to change it to an 'open eye' symbol. Now the release info should be visible on the overview.
    5. Click on tab 'Object attributes' and check the content of the field 'Href:' (the link must point to '{releasename}', not 'latest').
    6. Check also the content of the field 'Title:' to show the new release number and name (e.g. 'ONAP Release 9 »Istanbul«').
    7. Check and update all embedded links to point to '{releasename}' and not 'latest'. (to be detailed; search and replace in an text editor?)
    8. Save the file.
    9. Save the file a second time, but with a new filename. Use 'onap-architecture-overview-interactive-path.svg'.
    10. Then select all (warning) elements in the map and use the Inkscape function 'Path → Object to Path' to convert all elements to pathes. Read more about this in the onap-architecture-overview-notes.txt . Save the overview map, close Inkscape (and remember to do no (warning) further changes to this 'pathed' version of the overview).
    11. Info: In 'doc/docs/guides/onap-developer/architecture/onap-architecture.rst' you find a '.. raw:: html' section which contains the filename of the interactive ONAP architecture overview. You must use the filename of the 'pathed' version ('onap-architecture-overview-interactive-path.svg') here!

    EXAMPLE: 'onap-architecture.rst' for 'istanbul' branch

    › View in RTD

    OPEN: Describe how to update and test links in xls and svg.

    OPEN: Update links in 'onap-architecture-overview-interactive.svg' by using an editor and replacing very carefully '/en/latest/' with '/en/<newbranch>' ? Do all links work?

    OPEN

    Additional open topics

    • Include task for a review process for all documents authored by 'doc' to ensure that their content has relevance also for the new ONAP release?
    • Configuration of the RTD 'default version' ({releasename} as the starting point, not 'latest')
    • Tagging of the 'doc' branch (e.g. '8.0.0' for a main release or '8.0.1' for its first maintenance update)? Still required?
    • Describe the relation to the ONAP release lifecycle process (milestones)? And include the management of Jira tickets related to the described activities here in this procedure?
    • Stick embedded git file examples to a dedicated commit id to avoid that files are changed and then do not match anymore to the description in the task?
    • ReCheck/ReVerify in gerrit for projects which have created their '{releasename}' but where docs are not yet available in RTD?

    ...