Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[jakarta.ee-spec.committee] Review for approval: Spec Committee Meeting Minutes December 11th, 2019

The minutes for the December 11th Specification Committee call are below and are also available here. Please review and be ready for approval during our next call.

Spec Committee Agenda December 11, 2019

Attendees (present in bold):

Kenji Kazumura - Fujitsu - Michael DeNicola, Jacques Durand

Dan Bandera - IBM - Kevin Sutter, Alasdair Nottingham

Bill Shannon - Oracle - Ed Bratt, Dmitry Kornilov

Mark Wareham - Payara - Steve Millidge

Scott Stark - Red Hat - Mark Little, Antoine Sabot-Durand

David Blevins - Tomitribe - Jean-Louis Monterio

Ivar Grimstad - PMC Representative

Alex Theedom - Participant Member

Werner Keil - Committer Member


Eclipse Foundation: Wayne Beaton, Tanja Obradovic, Paul Buck


Past business / action items:

  • Approval of the minutes from the December 4th meeting. Mark moves to approve. Dan seconds. No objection. Motion passed.


Agenda

  • Discussion on next steps for the Jakarta-owned specifications that were removed in Java SE 11

https://github.com/jakartaee/specifications/pulls?q=is%3Apr+is%3Aopen+label%3Ajavase

    • Agreement: Unanimous support from committee to go forward to ballot and bring these specs in to Jakarta EE

      • Immediate next step is for committee members to give the specs a review to determine readiness to proceed to ballot

    • 12/11 - Ballots planned for mid-January. More participation requested, they will however be approved by lazy-consensus to be confirmed on the first spec committee call in the new year.

  • Jakarta EE 9 Plan Review for the Platform, Profile and stand-alone specifications

    • Combine the Plan Review step for all specifications that are participating Jakarta EE 9?

    • Agreement: Default is all specifications are in one plan review, those specifications that do not fit the base requirement of only moving from javax to jakarta would be an exception and require an individual plan review.

    • Idea (from David) - As part of the plan review, create a PR that shows all of the prospective specification versions (placeholders).  David will mock up an example and then we’ll move on from there…

    • 12/11 - Foundation guidance is that high-level plan with specification versions, content: javax → jakarta. Specification committee members can vote based on their own criteria with explanation. However we expect the vote to be a confirmation of the plan delegated to the Platform Project.

  • Migration from OSSRH to future Jakarta Nexus

    • Action Items:

      • David to provide an overview on the next call

        • Notes: Overview provided. Proposal approved to move the jakarta.* roles in a batch and request approval from the other roles (com.*, org.*) to move when and if they choose. Provide a recommendation and state the benefits.

      • 12/11 - Have “other roles” been notified? David volunteered to do that in the Steering Committee call on the 10th.

  • Review recent changes to the Operations document

https://github.com/jakartaee/specification-committee

12/11 - Scott to merge the to-dos and work on the approach for the project plans boards for Jakarta EE 9. Pull Request to be reviewed in call on the 18th.

  • Clarity on state of spec committee meetings taking place or not (MW added)

    • Notes: Add new spec committee members to shared calendar (if needed).

      • Shift to biweekly in 2020? Proposal to be brought forward on the 18th.

    • 12/11 - The committee will go biweekly in 2020.

  • How to get all Jakarta EE committers read access to any Jakarta EE CI (SMS added)

    • Notes: Request for committer read access to other/all EE4J projects. Issue needs to be filed. Scott to check and open an issue if needed.

    • 12/11 - Update from [Scott]

      • They appear to have this working for my [Scott’s] login, generalizing the access is in progress.

  • Optional Specifications Question from Mark - Notes: One open source compatible implementation has to implement the optional specifications as per the JESP. Idea proposed by Dan that in the future it could be adequate for a set of implementations to cover all of the optional specifications and optional features of specifications. If in the future we are to proceed with this approach the details will have to be considered and the final approach voted and approved by the Spec Committee.

Back to the top