Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-platform-dev] Fair rules for "optional" TCK compliance tests
The process for updating the EFSP is defined (it's just a bullet list, but I think that it gets the point across).

We're probably getting close to being ready to start that process for a handful of other potential updates. If you'd like to add something to the list, please open an issue.

At this point, I'm thinking that we convene a committee in the fall to sort out version 1.3 for 2021.

Wayne

On Tue, Jul 7, 2020 at 4:11 AM Emily Jiang <emijiang6@xxxxxxxxxxxxxx> wrote:
Personally, I think we should do this exercise to update the EFSP. In the past, the rules were defined based on the best knowledge. Now, we use Jakarta EE releases to test the rules. There should be a straightforward process for the feedback to be considered and the rules updated. I would vote for updating the Compatible Implementations not to force one Compatible implementation to implement all of the optional features. Having said that, I think Jakarta EE9 is unaffected by this exercise as Glassfish does implement all of the optional features. Right?


On Mon, Jul 6, 2020 at 6:17 PM Mike Milinkovich <mike.milinkovich@xxxxxxxxxxxxxxxxxxxxxx> wrote:

Yes, the JESP is approved by the Jakarta EE WG. But the JESP specializes the EFSP, it cannot contradict the EFSP on something as fundamental as the definition of Compatible Implementation.

On 2020-07-06 12:35 p.m., Scott Stark wrote:
But the EFSP is extended by the JESP. Cannot the JESP be updated without board involvement?

On Sun, Jul 5, 2020 at 8:44 PM Mike Milinkovich <mike.milinkovich@xxxxxxxxxxxxxxxxxxxxxx> wrote:
On 2020-07-02 7:05 p.m., Ed Bratt wrote:

I'd use 'requirements' instead of 'non-optional elements' but that's just me.

Since this is a language alteration to the EFSP, we'll eventually need to move this to the Spec. committee and then, I think we'll need some discussion at an even broader level.

The EFSP is now controlled by the Eclipse Foundation Board of Directors. A super-majority vote of the Board is required to change it. This puts it on par with the Eclipse Development Process.

There are also now multiple groups using the EFSP (Sparkplug, and soon AsciiDoc). They are certainly smaller and less complex than Jakarta EE, but their interests need to be respected when making any modifications.

Just wanted to make it clear that modifying the EFSP is now a more complex task than it was back in 2018 when it was being primarily formulated for the Jakarta EE Working Group.


--

Mike Milinkovich

Executive Director | Eclipse Foundation, Inc.

mike.milinkovich@xxxxxxxxxxxxxxxxxxxxxx

@mmilinkov

+1.613.220.3223 (m)

_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev


--
Thanks
Emily

_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev


--

Wayne Beaton

Director of Open Source Projects | Eclipse Foundation, Inc.

Join us at our virtual event: EclipseCon 2020 - October 20-22

Back to the top