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 November 20th, 2019

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

Spec Committee Agenda November 20, 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 - Richard Monson-Haefel, 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 November 6th meeting. Dan moves to approve. Mark seconds. No objection. Motion passed.


Agenda

  • Specification documents

    • Background

      • Jakarta _expression_ Language and JSON Processing were delivered by Wayne to the corresponding projects on November 6. Both have been approved by the IP Team.

        • No actual document for JSON Processing. Spec is entirely contained in the JavaDoc. AtInject is similar.

      • All documents have thus far been granted “checkin”. Some documents have been given these instructions by the IP Team.

        • During our initial review of this submission, we noted that the source code headers are either incorrect or missing. As this is a housekeeping issue only, you may proceed with checkin, however we would ask that the correct headers be added to the files per Eclipse standards. Please ensure that this is done and notify us via the CQ once this is completed.

      • No new news regarding the remaining documents at this point.

    • Discussion:

      • Wayne gave an overview of status that reflects what’s captured in the background. We do continue to receive periodic responses to our outreach to potential copyright holders, but have not reached a threshold yet to release any additional specification documents. We review our status approximately every four weeks; our next review is in early December, after which the Eclipse Foundation will update the Specification Committee.

      • The charts page of the Projects, Specifications, and Documents spreadsheet (in the Jakarta EE Specification Committee drive) includes charts that show state.

      • Ivar has created a “Jakarta EE Specification Documents” GitHub project that provides a more comprehensive overview.

      • Wayne suggested that a third chart showing adoption of the specification documents (i.e., projects that have pushed the documents into their repositories); that information is adequately tracked by the GitHub project, duplicating that information in the spreadsheet does not add value.

  • Plan Reviews

    • Discussion:

      • The EFSP requires that specification project teams engage in a Plan Review at the beginning of their development cycle. We briefly discussed whether or not we believed that this requirement is reasonable; consensus was that this requirement is reasonable and should be continued.

      • At least some specification projects have started making changes in their code bases (e.g., changing namespaces) without having first engaged in a Plan Review.

      • We decided (informally) that we will require that specification project teams engage in the required Plan Review following the release of the roadmap. This will likely mean that we will engage in related ballots in mid January.

      • We discussed mechanisms for capturing plan information and delivery of plans to the specification committee for ballot. David suggested that we reuse the specification pages as a means of capturing the plan (or at least plan summaries with pointers to more comprehensive plan documents). The idea being that the specification page for a particular version of a specification provides current status and serves as historical reference after the specification is ratified final. Pull requests can thereby be used to trigger requests for reviews, and potentially be used to run ballots.

      • Werner suggested waves in a similar way as Jakarta EE 8 specs were worked on because of inter-dependencies between those specs. E.g. JSON-B depends on JSON-P, etc.

    • Action Items:

      • David will mock up an example of a plan page that leverages the specification page format.

  • Migration from OSSRH to future Jakarta Nexus

    • Action Items:

      • David to provide an overview on the next call

  • Website updates for the Spec Committee. 

    • See this GitHub issue for background and to provide input.

    • Demo?

    • Discussion:

      • Wayne gave a quick impromptu demonstration of Hugo in action. It was a rough, ugly demonstration.

      • David reminded us that we’d decided to create a “committees/specification” folder for specification committee content, assuming that other committees may potentially create sibling folders.

      • We discussed options for putting content in the folder. Per previous discussions, content will need to be in a Hugo-supported format. Currently, Markdown and HTML are supported. Files that have a “Hugo” header will automatically pick up the site’s page layout.

      • Regarding existing content, we have some options. First, content (e.g. operations.adoc) can be converted from Asciidoc to Markdown (with headers) and included in the committees/specification folder. Another option is to use the Asciidoctor processor to render the Asciidoc content into bare HTML (HTML without headers/footers, etc.), add Hugo headers, and push the rendered content (manually) to the committees/specification folder. There may be potential to use automation in the specifications repository, but that must be explored.

      • The content from the operations.adoc can be moved to the website using something like the following command:

        • $ (echo -e "---\ntitle: \"Jakarta EE Specification Committee Operation\"\n---\n" && asciidoctor -s operations.adoc -o -) > ../jakarta.ee/content/committees/specification/operations.html

        • This is executed in the “specification-committee” repository root, and assumes that the jakarta.ee website repository has been cloned into the same parent folder.

      • Wayne did a little experiment after the call to test conversion of the existing operations.adoc file into Markdown.

        • $ asciidoctor -b docbook operations.adoc

        • $ pandoc -f docbook -t markdown operations.xml -o operations.md

        • (manually-added header)

        • AFAICT, the document does not use advanced features in Asciidoctor that are not present in Markdown. The initial output is a little rough (there may be options in the conversion tools that will help with this); the document is relatively short, so manual clean up should not be particularly onerous.


Back to the top