Thank you so much Paul. This provides clarity. We will proceed.
Thanks,
Ed
| Reply anonymously to this email:
https://purl.oclc.org/NET/edburns/contact
From:
Paul Buck <paul.buck@xxxxxxxxxxxxxxxxxxxxxx>
Date: Wednesday, January 17, 2024 at 12:59
To: Ed Burns <Edward.Burns@xxxxxxxxxxxxx>
Cc: Jakarta specification committee <jakarta.ee-spec.committee@xxxxxxxxxxx>, Jakarta EE Steering Committee <jakarta.ee-steering@xxxxxxxxxxx>
Subject: Re: [EXTERNAL] Re: [jakarta.ee-steering] [jakarta.ee-spec.committee] Follow up actions from 2024-01-10 regarding Java SE level for EE 11
I assume the Platform Project will proceed according to its revised plan that you have communicated. This should be of no surprise to anyone as the revised plan was developed openly by the Platform Project with input from committers and
member representatives. What remains is for the Specification Committee to deal with the formality around the revised plan.
Hello Spec-committees,
I am writing this email in my capacity as release co-coordinator. I urgently request the stakeholders to consider acting before waiting a whole entire
week.
It seems to me the operative questions are:
-
Does the action taken by the platform project to mitigate
gh-platform-820 require a vote?
-
If so, what kind of vote is required?
Please consider making progress on the operative questions, however you may want to shape them, asynchronously. Perhaps via email?
As I continue to say, my prime concern is keeping the June/July target for EE 11 done. The longer this matter remains unresolved, the more difficult
this becomes.
Sincerely,
Ed Burns
Release co-coordinator
| Reply anonymously to this email:
https://purl.oclc.org/NET/edburns/contact
Thanks Will for raising this situation and Wayne for your guidance.
I will add this topic to the agenda on the Specification Committee call next Wednesday (24th).
Changing the base version of Java SE is not a scope change. The scope that the EFSP refers to is "The defined scope of activities for a Specification Project." Specifically, this
is the scope as it is described on the Eclipse Specification Project's "Governance" page in the
PMI, which says nothing about the required Java SE version.
The plan that was approved by the specification committee in August included a statement that "Minimum Java SE Version" is "Java SE 21 or higher". Any deviation from that is a deviation
from the approved plan. The specification committee needs to decide what to do about the deviation.
The EFSP is being followed and working as intended. This version needs to be approved by the specification committee by supermajority ballet before it can be released. As part of
their decision, members of the specification committee will have to decide whether or not the deviation from the plan is grounds enough to vote -1 in that ballot.
In the meantime, the specification committee could consider sending a warning to the project that by deviating from the agreed-upon plan, they risk losing the release ballot (the
specification may also argue that they've been monitoring this situation as it develops which suggests that they implicitly agree with the change). Or the specification committee might also consider requesting a new Plan Review for the revised plan. I can
join the next specification committee's next meeting to discuss these options if needed.
Ed/Arjan –
Thank you for the thorough mail and ongoing coordination of this release.
Spec Committee (and ccing Steering Committee members) –
Steve Millidge commented at today’s Steering Committee meeting that this is a significant change in plan and that no vote was
taken on this change. Leaving aside the actual merits of this change in plan, I believe his concern that the JESP should be followed is valid. During the Steering Committee meeting I said I would review the JESP to assess whether I believed that the process
has been followed.
See below for my detailed assessment[1] but in summary I believe that, without a vote, the JESP process has not/is not being followed
properly, and Oracle feels strongly that it should be followed properly. The change in minimum Java SE version support represents a significant change to the scope of the Jakarta EE 11 Spec Project(s), and under those circumstances a super-majority of the
Spec Committee must approve the change in Scope, and that implies to me a vote where the super-majority is recorded, probably in the form of a ballot. I think it would be sufficient to have a single ballot for Jakarta EE 11 overall (e.g. a Platform Spec change)
vs one for each spec, but I believe a recorded vote with a super-majority approval is required.
I request that the Spec Committee hold a recorded vote to approve this change. If it is required that a Spec Committee member make
such a request, I will discuss that with Ed Bratt.
Thanks
Will
[1]Detailed assessment:
-
Specification Projects operate under the supervision of both the Project Leadership Chain and their Working Group’s Specification
Committee.
-
At the time of creation, a Specification Project must provide a well-defined Scope that is bounded by the Scope of its Top-Level Project. Since a change in Scope may change the nature of the project, a change to
a Specification Project’s Scope must be approved by a Super-majority of the Specification Committee.
-
A new Specification Project may be created via Project Proposal and Creation
Review; alternatively, an existing Project may be converted into a Specification Project via Restructuring
Review.
-
Here is what I observe for the Jakarta EE 11 Platform Spec (for example):
-
This link above says “Minimum Java SE Version Java SE 21 or higher”.
-
I am not aware of any subsequent ballots on the Platform Spec.
-
AFAICT, the Jakarta EE 11 Platform Spec Project was created as a result of the August ballot which specifically targeted “Minimum Java SE Version Java SE 21 or higher”.
-
Java SE 21 or higher is the only bolded item on the page
above, and this reflects the focus placed on Java SE 21 in release conception. Based on the importance of Java SE 21 support at the time of Project Creation, and the work impact of adding another Java SE version, I consider adding support for another
Java SE version to be a material change in “Scope” to the Project.
-
The JESP/EFSP says “a change to a Specification Project’s Scope must be approved by a Super-majority of the Specification Committee”. The use of the term “Super-Majority” implies to me that a vote must be taken
on the change, with the super-majority verified.
-
Such a vote has not occurred. Therefore my interpretation is that the change to the Scope of the Jakarta EE 11 Platform Spec Project is not properly following the JESP/EFSP.
-
I recommend/request that a Spec Committee vote be held, and if the super-majority is achieved to change Scope, that the super-majority be recorded.
Hello Spec committee,
We consumed a lot of valuable time in the 2024-01-10 meeting on the matter of the Java SE level for EE 11. We discussed this at length in the platform project, in email, in ad hoc
meetings, and at the platform project weekly meeting. Here are the
revisions to the EE 11 release plan devised by the platform project. I will copy from the email
archive for your convenience.
-
Platform project keeps the June/July 2024 target for having an EE 11 Ratifying Compatible Implementation.
-
Platform project adjusts JDK compilation requirements:
-
Component spec TCKs and platform TCK must compile under 17.
-
A compatible component impl must pass their component TCK when run under 17 or 21.
-
To ratify a component specification, there must exist an implementation that passes on 17. There must also exist an implementation that passes on 21.
-
These need not be the same implementation. There can be one implementation that passes on 17 and a different one that passes on 21.
-
A compatible platform impl must pass the platform TCK when run under 17 or 21.
-
To ratify a platform specification, there must exist an implementation that passes on 17. There must also exist an implementation that passes on 21.
-
These need not be the same implementation. There can be one implementation that passes on 17 and a different one that passes on 21.
-
This is the same situation as was the case with Jakarta EE 10. For EE 10, it was JDK 11 and 17. For EE 11 it is JDK 17 and 21.
-
Wave 1, 2, 3, 4 specs release review by 2024-02-29
-
M2 release
-
Wave 5 specs release review by 2024-03-29
-
M3 release
-
Wave 6, 7 specs release review by 2024-04-27
-
M4 release
-
The key condition to make this plan possible: the GlassFish community is willing and able to deliver an implementation of EE 11 compiled under 17, but passing the platform TCK under 17 and also 21. The release coordinators
expect more community involvement on the Jakarta Data implementation for GlassFish, especially from Red Hat, to achieve this goal.
These changes have been applied to the release plan in PR
822. The important text is on lines
52 - 64 of the release plan.
Based on what I heard from Wayne in the 2024-01-10 call, no ballot is required for a plan change, because the release review that implements this change will include a vote.
Please let me know if further action is necessary.
Thanks,
Ed and Arjan
Jakarta EE 11 release co-coordinators.
| Reply anonymously to this email:
https://purl.oclc.org/NET/edburns/contact
_______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee
--
Wayne Beaton
Director of Open Source Projects |
Eclipse Foundation
My working day may not be your working day! Please don’t feel obliged to read or reply to this e-mail outside of your normal working hours.
_______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee
|
