Carrier Billing APIs Readiness Checklist MetaRelase Fall24

[PedroDiez]

What type of PR is this?

Add one of the following kinds:

• documentation
• subproject management

What this PR does / why we need it:

PR to update API readiness Checklist for Carrier Billing Family APIs
PR shows expected output for MetaRelease

Which issue(s) this PR fixes:

Fixes #163

Special notes for reviewers:

To be merged after #165 is MERGED and Issues #159, #162 are CLOSED

Changelog input

 Carrier Billing Family APIs Readiness Checklist for MetaRelease Fall24

Additional documentation

N/A

[github-actions]

🦙 MegaLinter status: ✅ SUCCESS

Descriptor	Linter	Files	Fixed	Errors	Elapsed time
✅ ACTION	actionlint	2		0	0.03s
✅ OPENAPI	spectral	2		0	4.05s
✅ REPOSITORY	git_diff	yes		no	0.05s
✅ REPOSITORY	secretlint	yes		no	1.01s
✅ YAML	yamllint	2		0	0.84s

See detailed report in MegaLinter reports

MegaLinter is graciously provided by

[bigludo7]

Thanks @PedroDiez - will wait for the required missing pieces.

[hdamker]

Looks good to me, see two hints above.

BTW: the final updates of the table are meant to be made within the Release PR, so that the merge commit of the Release PR is the one which get tagged. Otherwise the Release PR is not complete, if the checklist will come afterwards.

[PedroDiez]

@hdamker
Intention with this PR was to have ready API readiness Checklist with M4 horizon. Given the fact that:

• User Stories have to be updated
• Initial Test Plan have to be provided

And be ready for M4 milestone. That was what we commented within the WG

So in this way M3 (Release Candidate PR): #167, is focused on YAML.

Therefore, should I adapt this PR to "show" the status for M3 and generate afterwards a new PR for the M4 milestone, once User Stories and Testing Plan is provided?

[hdamker]

Therefore, should I adapt this PR to "show" the status for M3 and generate afterwards a new PR for the M4 milestone, once User Stories and Testing Plan is provided?

Yes, that is the intention from Release Management perspective ... the checklist should reflect the current status of the (pre)release. And it's ok if the User Stories and Test Definitions are "tbd" in the release candidate (the latter is an exception decided by the TSC for this release cycle).

For the following releases, e.g. the one for M4, you only need to update the few details in the checklists as part of the Release PR, no separate PR needed for that.

[hdamker]

LGTM ... just two comments which can also be done in the release PR.

Link to changelog will be /CHANGELOG.md, permanently :-)

[PedroDiez]

I will do in this PR as I think it needs at least RM approval to be able to be merged

[hdamker]

LGTM from Release Management perspective

[hdamker]

I will do in this PR as I think it needs at least RM approval to be able to be merged

In RM we are reviewing the checklist(s) together with the release PR.
As the checklists are now perfect, should I merge them for you? (otherwise you would one Codeowner approval).

[PedroDiez]

I will do in this PR as I think it needs at least RM approval to be able to be merged

In RM we are reviewing the checklist(s) together with the release PR. As the checklists are now perfect, should I merge them for you? (otherwise you would one Codeowner approval).

If possible, yes please, it is appreaciated if you can merge it Herbert