Jakarta Config 1.0 Progress Review

[Pandrex247]

The Plan Review for version 1.0 concluded on the 26th of January 2023: https://www.eclipse.org/lists/jakarta.ee-spec/msg02821.html
As per the Jakarta EE Specification Process, Jakarta Config 1.0 is due a Progress Review.

A request has not been explicitly made for a Progress Review, this is purely procedural to comply with the process. As such, all that is needed is to confirm that the plan as previously agreed is still valid and that checkpoint artifacts (Milestone builds, TCK updates, etc.) previously agreed to have been produced.

Please reach out to me or comment on this issue if anything is not clear and as your assigned mentor I will see what I can do to help.

Below is the checklist we will be using to review.

1. Spec PR for Plan / Proposal

• There is no new material that wasn't previously provided that would impact the existing Specification "work in progress" page layout.

2. _index.md

• If there are milestones previously approved and/or documented on the Specification page, but now out of date, or not feasible (missed checkpoints or other milestones), there must be a proposed PR to refresh the previously approved plan material.
• The progress review should demonstrate the agreed plan is still correct and accurate. If it is not, the Progress Review is an opportunity to revise the plan as needed.
• Mentor to confirm (via consultation with committer team) the scope is correct. If it has been revised, those changes should be summarized. Regardless, the committer team is responsible for providing any statements or documentation describing progress for the progress review materials.
  • The mentor may wish to review the Plan Review Ballot checklist to confirm all items are captured.
  • If checkpoint or scope material is derived from issues or epic issues, the mentor may wish to request the committer team provide a summary statement of the specific progress against the issue or issues.
  • The committer team should provide an overall assessment that confirms they are "on track" or produces a plan revision that reflects the evolution since the last ballot.
• The mentor should focus material for this review on progress of this specification revision and not the progress or changes associated with higher level projects (i.e. it is probably insufficient to say "schedule changed in Platform Release Plan so we're changing too"). Scope changes that have been imposed on this specification may certainly be noted and may be a source for plan revisions.
• Any changes or additional requirements, resource needs (e.g. CI/CD resources), feature changes, etc. should be reflected in the specification plan revision. If there are no changes the committer team should be able to demonstrate that they are progressing within the original plan that is already approved.

3. Proposed Spec PDF (Optional)

• Correct spec title, clearly marked preliminary
• Correct Eclipse copyright line
• Must indicate DRAFT or SNAPSHOT
• Correct Logo

4. Proposed Spec HTML (Optional)

• Same as PDF

5. TCK

• Some statement or evidence of TCK development progress and accomplishment from previous review