Meta-release feedback

Please add your comments / feedback on the RM process here:

Fall24

  • add link to release PR review guidelines (M3) on Confluence in the review issue template (Guidance for release PR review - CAMARA Project - Confluence)

  • https://github.com/camaraproject/ReleaseManagement/issues/83#issuecomment-2326205649 include the changelog titles guidelines e.g. "r1.1 - rc"

  • API release tracker template updates

    • Meta-release. Do we keep "N/A" or should we use "Sandbox" ?

    • remove "M5 date" field from the API release tracker template as for APIs M3 and M4 are the milestones โ†’ DONE

    • reorder fields: M3 date; pre-release tag link; M4 date; pre-release tag link โ†’ DONE

    • rename the "Target Maturity" to "Maturity level" (or "Maturity") ? โ†’ DONE

    • Should we add "Sandbox in the Maturity level field ?

    • add a "RM status" field to hold links to GitHub RM review issues โ†’ DONE

      • can we show the issue status in confluence ?

    • add an API definition field with a direct link to the yaml ? โ†’ NO use the release link - check that the Changelog containds it.

    • check guidelines on how to fill the "Repository" field should be just the repo name โ†’ DONE

    • should we rename Group to Sub Project ?

  • remove LICENSE file from TEST folder in repository template โ†’ DONE. Remove it where it still may exist.

  • ย I think it would be an enhancement to reflect clearly per release since which version is the changelog consolidated, as kubernetes does for example:
    - see:ย https://github.com/camaraproject/DeviceLocation/pull/252#issuecomment-2312647764 Edit th eCHANGELOG template to indicte this in the header of the major release section.

  • Kuberneters has a changelog folder with per release files per release - @Tanja de Groot Tanja to chek

  • Create an ICM review issue template for stable APIs or add these in the RM review issue template ? see ICM section in Review guidance for API release PRs

  • update template text "Telco Operator as API provider" to "API provider"

  • Reduce the time to produce "CAMARA-compliant" APIs. Currently the development process is reactive - API authors manually interpret the guidelines and paste in common artefacts (which may change), then reviewers and linters point out errors and the author resubmits. A browser-based 'CAMARA IDE' (e.g. a fork of Swagger Editor) could enforce guidelines while editing, include latest boilerplate text and common code blocks, enforce the correct version and URL syntax etc. - which should in turn reduce the time-to-review each API.ย (Kevin Smith)

ย 

ย