Final call on the
PRs for the JESP and Operations Guide! I'm out until Tuesday. If
there are no complaints, then hopefully we can call this "done",
merge the PRs, and communicate our Service Release process to the wider
teams. Thanks for your help!
PR
#1050 (JESP):
PR
#1047 (Ops Guide)
---------------------------------------------------
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)
From:
Kevin
Sutter/Rochester/IBM
To:
Jakarta
specification committee <jakarta.ee-spec.committee@xxxxxxxxxxx>
Date:
02/18/2021
16:35
Subject:
Re:
[EXTERNAL] Re: [jakarta.ee-spec.committee] Where are we at in regards to
Service Releases?
NM. I would
assume you want a similar update for the JESP. I've made that change
as well. 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)
From:
"Kevin
Sutter" <sutter@xxxxxxxxxx>
To:
Jakarta
specification committee <jakarta.ee-spec.committee@xxxxxxxxxxx>
Date:
02/18/2021
16:20
Subject:
[EXTERNAL]
Re: [jakarta.ee-spec.committee] Where are we at in regards to Service Releases?
Sent
by: "jakarta.ee-spec.committee"
<jakarta.ee-spec.committee-bounces@xxxxxxxxxxx>
Thanks, Scott.
I found the comment about "no increase in IP scope" for the ops
guide. I'm good with that. But, you mentioned that you made
a comment on each PR. I can't find anything on the other PR...
---------------------------------------------------
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)
From: Scott
Stark <sstark@xxxxxxxxxx>
To: Jakarta
specification committee <jakarta.ee-spec.committee@xxxxxxxxxxx>
Date: 02/18/2021
14:14
Subject: [EXTERNAL]
Re: [jakarta.ee-spec.committee] Where are we at in regards to Service Releases?
Sent by: "jakarta.ee-spec.committee"
<jakarta.ee-spec.committee-bounces@xxxxxxxxxxx>
Ok, I made a comment on each PR that clarifies the definition enough for
me.
On Thu, Feb 18, 2021 at 11:07 AM Kevin Sutter <sutter@xxxxxxxxxx>
wrote:
Well, you tell me... :-)
From PR
#1050 (JESP):- Service Releases (x.y.z)
- A Service Release includes only minor
changes and/or clarifications over a Major or Minor Release. Specifically,
a Service Release must not include any functionality changes. A Specification
Team may consult with their PMC and Specification Committee to determine
precisely what constitutes a minor change and/or clarification.
- A Specification Team must have engaged
in a successful Release Review for a Major or Minor Release prior to engaging
in a Service Release. No Progress or Release Review is required for a Service
Release.
From PR
#1047 (Ops Guide)(Note
that there would still be a note to the Spec team asking for the review
of the PR. At least one member of the Spec Committee would have to
approve the PR and do the actual merging. We just wouldn't have the
formal vote across the whole Committee.)
Creating a Final Service Release Specification # {#creating_a_final_service_release_specification}
There is no formal release review required for a Specification service
release (x.y.z) as long as the JESP definition of a "service release"
is adhered to. That is, no functionality changes are permitted in a service
release. Although much of the content of the Final Specification still
applies, the approval process is simplified for a service release.- The creation and staging of the
various artifacts (Specification, API, and/or TCK) are still performed
via the initial
steps 1 and 2 outlined above.
- The creation
of Specification PRs in step 5is
also required.
- The Specification Project team
should then send a note to the public
Specification Committee mailing listannouncing
that the PRs are ready for review.
- After the Specification PRs are
reviewed and approved by independent specification committee members, the
PRs can be merged. The Specification Project team can then release the
staged artifacts to Maven Central.
---------------------------------------------------
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)
From: Scott
Stark <sstark@xxxxxxxxxx>
To: Jakarta
specification committee <jakarta.ee-spec.committee@xxxxxxxxxxx>
Date: 02/18/2021
12:54
Subject: [EXTERNAL]
Re: [jakarta.ee-spec.committee] Where are we at in regards to Service Releases?
Sent by: "jakarta.ee-spec.committee"
<jakarta.ee-spec.committee-bounces@xxxxxxxxxxx>
As long as we have a clear definition on what a non-functional change is,
then this should work.
On Thu, Feb 18, 2021 at 10:49 AM Kevin Sutter <sutter@xxxxxxxxxx>
wrote:
Scott,
Thanks! I agree that the javadoc is an extension of the spec document.
It actually *was* the spec document in most cases in Jakarta EE 8.
When we discussed this on a Spec Committee call, the discussion centered
around trusting and assuming the projects will do the right thing and not
introduce any functional changes in a service release. That is, if
we have defined what a service release is (with the two proposed PRs),
then Spec Projects need to adhere to this requirement of no functional
(or behavior) changes in a service release. And, allow the Spec Projects
to deliver service releases on their own schedule and with no formal ballot
as long as a major or minor release was performed within the last 12 months.
If it is later determined that a Spec Project violated that requirement,
they would immediately be required to go through a full release cycle for
a new major or minor release.
And, if it's later determined that Spec Projects in general are violating
this requirement, then we'll have to go back to full release reviews with
ballots for all major, minor, and service releases.
Would this satisfy your question?
---------------------------------------------------
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)
From: Scott
Stark <sstark@xxxxxxxxxx>
To: Jakarta
specification committee <jakarta.ee-spec.committee@xxxxxxxxxxx>
Date: 02/18/2021
11:55
Subject: [EXTERNAL]
Re: [jakarta.ee-spec.committee] Where are we at in regards to Service Releases?
Sent by: "jakarta.ee-spec.committee"
<jakarta.ee-spec.committee-bounces@xxxxxxxxxxx>
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) ReleaseChanges
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_______________________________________________
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
_______________________________________________
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_______________________________________________
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
_______________________________________________
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_______________________________________________
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
_______________________________________________
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
_______________________________________________
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
