Re: [jakarta.ee-spec.committee] Maintenance Reviews

[Bill Shannon <bill.shannon@xxxxxxxxxx>]

In general, I think using EDP Service Releases to replace JCP Maintenance Reviews can be made to work.

I would like to see the process for a spec Service Release described more explicitly, and ideally moved to a separate section.  There are many requirements in the Specification Process section that don't apply to Service Releases so it's hard to understand exactly what is and is not required.  What initiates a review by the Specification Committee of a Service Release for a spec, how long does it last, what information needs to be provided, what needs to happen with the CI and TCK, etc.?  The EDP has no reviews for service releases, so all of that needs to be defined here.

There's a lot more detail in the JCP process document about Maintenance Releases, but I suppose we can defer adding that level of detail here until we find that we actually need it.

Wayne Beaton wrote on 12/13/18 08:34 PM:

According to the JCP (2.11.6), in the context of a Maintenance Review:

Changes appropriate for a Maintenance Release include bug-fixes, clarifications of the Specification, changes to the implementation of existing APIs, and implementation-specific enhancements. Changes introduced in Maintenance Releases – for example, modifications to existing APIs or the addition of new APIs - must not break binary compatibility as defined by the Java Language Specification.

The document also describes the role of Maintenance Lead and specific details around releases.

Service Releases, as presented in the EFSP, are considered "Bug Fix" releases. The definition of Service Release and Bug-fix are not formalized beyond a simple qualification that Service Releases contain "no significant changes or additions over the base Release". In the absence of any formal definition of what constitutes a significant change or addition, the definition is left to the Project Leadership Chain. 

I believe that we can reasonable ask the PMC to assert that the sorts of changes that are acceptable in a JCP Maintenance Release are also acceptable in an EDP/EFSP Service Release (though, I'm not quite sure what is intended by "implementation-specific enhancements"). 

Regarding approvals, the EFSP has this to say about Service Releases:

Service Releases (bug fixes) for a Specification Version that has engaged in a successful Release Review do not require any further Reviews, but must be approved by a Super-majority vote of the Specification Committee.

How a vote is run, the materials that must be delivered to the Specification Committee in advance of a vote, timing considerations, etc. may be formalized in the implementation of the process.

The one possible oversight that I can see is that the EFSP specifically states that:

With the successful completion of a Release Review, including approval of the Specification Committee by a Super-majority vote, a Specification Version is Ratified and the associated artifacts can be promoted and distributed by the Specification Committee as a Final Specification.

This does not make allowances for Service Releases. I believe that this can be corrected by removing the reference to the Release review and going with something like this:

With the <strike>successful completion of a Release Review, including</strike> approval of the Specification Committee by a Super-majority vote, a Specification Version is Ratified and the associated artifacts can be promoted and distributed by the Specification Committee as a Final Specification.

And, perhaps, formalize that the output of a Service Release is also a Specification Version.

What am I missing?

Thanks,

Wayne

--

Wayne Beaton

Director of Open Source Projects | Eclipse Foundation, Inc.

_______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee