Re: [jakarta.ee-spec.committee] Where are we at in regards to Service Re

[Scott Stark <sstark@xxxxxxxxxx>]

So a spec team basically needs sign off from the specification committee on whether a vote can be bypassed. That still is essentially a lazy consensus vote that needs some initiation to involve the specification committee because we don't want to have people outside of the team arguing that spec of api changes were actually made. Several specs do document behavior in javadocs comments and are essentially extensions of the spec document.

On Wed, Feb 17, 2021 at 6:57 AM Kevin Sutter <sutter@xxxxxxxxxx> wrote:

Hi,
I'm confused where we are at in regards to allowing simple Service Releases.  Here are the minutes from when we last discussed this:

• Continue working on the Release Review requirement for a Service (Patch) Release
  • PR for the updated JESP - https://github.com/jakartaee/jakarta.ee/pull/1050
  • PR to Modify ops guide for a Service Release - https://github.com/jakartaee/jakarta.ee/pull/1047
  • Issue created against the EFSP - https://github.com/EclipseFdn/EFSP/issues/29
  • Refine the definition of “significant” in the EFSP to be “No functionality changes whatsoever to the specification” in the JESP. Consider applying the condition to just the specification document.
  • Is a ballot always required? The Specification Committee acts in its best judgement whether a ballot is needed.
  Changes to the EFSP regarding Service Release will be contemplated in the next rev of the process.
  • Open issues to the EFSP as required
  Wayne to investigate leveraging an “errata” approach to handling no-functionality-changes.
         https://github.com/EclipseFdn/EFSP/issues/32

We have several Specifications that would like to do a service release (x.y.z) in the very near future.  These are not considered part of Jakarta EE 9.1, but we still need to communicate a process to them.

If I go off of this statement from the minutes:  Is a ballot always required? The Specification Committee acts in its best judgement whether a ballot is needed.
Then, don't we have the liberty to forego a formal ballot for a service release?  And, thus my PRs for updating the JESP and our Operations Guide are valid until we get further clarification defined at the EFSP level?

We are already allowing service releases for the TCK without any fanfare.  We've already done a 9.0.1 and 9.0.2 TCK release.  Can't we do the same thing for the Javadoc updates via the APIs?  As long as we're firm on the requirement of no functional changes (and that's spelled out in the PRs above), then we should be good to go.  Right?

Please comment so that I can provide a better answer to the teams looking to produce service releases.  Thanks!

---------------------------------------------------
Kevin Sutter
STSM, Jakarta EE and MicroProfile architect @ IBM
e-mail:  sutter@xxxxxxxxxx     Twitter:  @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)    
LinkedIn: https://www.linkedin.com/in/kevinwsutter

Part-time schedule: Tue, Wed, Thu (off on Mon and Fri)
_______________________________________________
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