MicroProfile OpenAPI 4.0 Specification Review

[Azquelt]

Specification issue template

When creating a specification project release review, create an issue in the MicroProfile-WG repository repo with the content defined as follows.

• Specification name and version
• Add the label Release Review
• Naming conventions for artifacts:
  • Specification PDF in the form of microprofile-project-spec-version.pdf
  • Specification HTML in the form of microprofile-project-spec-version.html
  • project is the microprofile specification short project name (config, health, ...)
  • version is the two digit x.y version of the specification

• The Nexus Staging links (orgeclipsemicroprofile-NNNN where NNNN is the staging repository id) (eg, https://oss.sonatype.org/content/repositories/orgeclipsemicroprofile-NNNN/org/eclipse/microprofile/config/) which contain all the binaries and relevant documentation:
  • Staging Repo
  • Spec PDF
  • Spec HTML
  • Javadoc
  • API Jar
  • TCK Jar

• A link in the Eclipse downloads sections is still available for specs and apidocs:
  • https://download.eclipse.org/microprofile/staging/microprofile-open-api-4.0/
  • An apidocs directory containing the javadoc associated with the API jar.

• Summary that a Compatible Implementation is complete, passes the TCK, and that the TCK includes sufficient coverage of the specification.
  • Compatible Certification Request

• Release Review
  • Follow governance process and create/update release record
    • Component Release Record
  • Email to PMC (more info here)
  • Start release review by emailing EMO (more info here)(Track the bug issue created by EMO after the email)
  • A member of Steering Committee initiates the ballot by sending an email to [microprofile-wg] (mailto:[email protected]) (more info here
  • After the voting has ended, email [microprofile-wg] (mailto:[email protected]) with the ballot result (more info here
  • https://www.eclipse.org/lists/microprofile-wg/msg02582.html

[Azquelt]

The release had to be withdrawn and re-staged because the TCK dependency on MP Rest Client had not been updated to 4.0.

I have updated all the links above. The compatible implementation will need to be re-tested against the newly staged release and the CCR updated with the new results. The linked CCR has now been updated.

[Azquelt]

The release had to be withdrawn and restaged again due to a build bug which meant the javadoc and API jar weren't copied to the eclipse download staging site. This was fixed by eclipse/microprofile-build-infra#15.

The links and CCR above have been updated accordingly.

[mtdelgadoa]

Hello all,
the EMO is trying to avoid duplication of release records, so we will be providing our feedback and comments related to this release directly here.

EMO REVIEW CHECKLIST

EDP Review status: ONGOING - EMO ready + awaiting Spec Committee Ballot

EMO review checklist

PMI record: https://projects.eclipse.org/projects/technology.microprofile/reviews/microprofiler-openapi-4.0-release-review

EF Specification Process

• Spec Committee Ballot completed

Intellectual Property Management

• All project code has copyright and license headers correctly applied. ** EMO will scan the code at their discretion **
• All distributed third-party content has been vetted by the IP Due Diligence process (i.e., IP Log has been approved)

Open Source Rules of Engagement

• PMC approval on the mailing list

General:

• Project is operating within the mission and scope defined in its top-level project’s charter
• Project is operating within the bounds of its own scope
• Project is operating in an open and transparent manner
• Overall the project is operating according to the Eclipse Development Process.

Things to check:

• Communication channels advertised
• Advertised communication channels used
• Committers are responding to questions
• Committers are responding to issues
• Committers are responding to pull/merge/review requests

Branding and Trademarks
The following applies when the project has a custom website.
To the best of our knowledge:

• Project content correctly uses Eclipse Foundation trademarks
• Project content (code and documentation) does not violate trademarks owned by other organizations

Things to check:

• Project website uses the project's formal name in first and all prominent references
• Project website includes a trademark attribution statement
• Project website footers contain all necessary elements

Legal Documentation
Required files:

• License files in all repository roots
• README
• CONTRIBUTING (or equivalent)

Recommended files:

• NOTICES or equivalent (you can use the Legal Documentation generator available under committer tools)
• CODE_OF_CONDUCT
• SECURITY

See examples for Security file and Code of Conduct.

Required elements:

• ECA is referenced/described

Recommended elements:

• Build instructions provided
• Security policy is described

Metadata (PMI)

• The formal name, e.g. "Eclipse Foo™", is used in the project title
• The formal name including appropriate marks (e.g, "™") is used in the first mention in the text of the project description, and scope
• The project description starts with a single paragraph that can serve as an executive summary
• Source code repository references are up-to-date
• Download links and information are up-to-date (see EF handbook for more information on how-to do this)
• Communication channels listed in the PMI (i.e. public mailing list, forums, etc.)

[jclingan]

@mtdelgadoa Due to incorrect EFSL verbiage, we had to update Open API 4.0 to use EFSL 1.1 and rebuild. This would change the build links in this issue. Should I update this issue or create a new one? This will also apply to the Rest Client specification review.

[Azquelt]

For now, I've updated the links in the issue, let me know if we need a new issue instead.

[jclingan]

@mtdelgadoa I will update this issue with links to the new repository and spec with EFSL 1.1.

[Emily-Jiang]

The ballot concluded successfully (see here) @mtdelgadoa