Re: [jakarta.ee-spec.committee] Jakarta EE 8 certification goal

[Mike Milinkovich <mike.milinkovich@xxxxxxxxxxxxxxxxxxxxxx>]

Richard,

I am pretty sure that this is exactly what Wayne Beaton said in his email from Wednesday, except that he called it a "Specification Committee".

On 2018-05-10 12:56 PM, Richard Monson-Haefel wrote:

Sorry. That was unclear. I mean could there be, for example, a Reactive Streams PMC made up of the leaders fro the Reactive Streams API, Ref, TCK, and Spec working groups?  Each working group would have its own leader and committers (with overlap if necessary) but the PMC for Reactive Streams would coordinate their output.

On Thu, May 10, 2018 at 11:54 AM, Richard Monson-Haefel <rmonson@xxxxxxxxxxxxx> wrote:

Maybe this is too complicated but could there be a PMC-like-thing for each subproject (API, Ref, TCK, Spec) made up of the leads from each subproject?  The leads can coordinate their work while maintaining enough separation so that each subproject is manageable.

On Wed, May 9, 2018 at 4:40 PM, Bill Shannon <bill.shannon@xxxxxxxxxx> wrote:

My understanding was that most people wanted the "API" projects to contain the API Java classes, the API specification document, and the TCK for the API, each as separate repositories under that project.  If so, how does the Eclipse Development Process handle releasing artifacts from each repository independently?  Are they just considered project releases that only produce one of the project artifacts? Can there be multiple project plans active simultaneously?

While "major" updates to API projects would likely synchronize changes to all 3 repositories (along with the RI repository), "minor" updates might not.

I assume coordination between API and RI projects is the responsibility of the Project Leads for the two projects, if they're not the same people.

Another thing to keep in mind is that the implementations for some Jakarta EE specs are not "separate", they're part of GlassFish.  Coordinating updates to GlassFish with updates to all these other artifacts is a non-trivial task.  it's not just a matter of sweeping all the piece parts into the same box and releasing it.

Steve Millidge (Payara) wrote on 05/ 9/18 05:02 AM:

Reusing as much of the EDP as possible is a good way forward for developing the actual outputs that make up a spec.

 

 

I’ve taken Wayne’s thoughts below and attempted to show them in a straw man picture (attached) to illustrate the number of projects involved and the process between them. Blue is in EE4J and Brown is in Jakarta EE. Note the top 5 swim lanes will be duplicated n times to make up a profile where n is the number of specs in the profile. Note the added complexity that some projects incorporated in a profile are not in EE4J or developed at the Eclipse Foundation 😊

 

So my understanding is that the individual EE4J project(s) iterate the API, RI, TCK and Specification document to create a release using the EDP? However it is likely that the API, RI, TCK and spec are different Eclipse projects under EE4J so some coordination between them is required to create a candidate spec release. Is that managed within the EE4J PMC or in Jakarta EE?

 

The spec committee then ratifies the 4 outputs as an individual spec using some process to be defined? Possibly a simple vote within the spec committee?

 

A missing step from below is incorporation of the individual specification into a profile release. I would assume a profile (in the profile spec) will impose some internal consistency requirements on an individual spec before it is admitted to a profile. I’ve not added this feedback loop to the picture.

 

For profile releases I would advocate a release train model similar to what is currently done within the Microprofile project. In that a profile “sweeps up” whichever relevant individual specifications meet the profile requirements at their point releases and then releases a profile. The profile will very likely require an EE4J project for Profile TCK, Profile RI and Profile Spec document. These outputs will then require ratification via the spec committee?

 

 

 

Steve

 

From: jakarta.ee-spec.committee-bounces@xxxxxxxxxxx <jakarta.ee-spec.committee-bounces@xxxxxxxxxxx> On Behalf Of Wayne Beaton
Sent: 08 May 2018 20:45
To: Jakarta specification committee <jakarta.ee-spec.committee@eclipse.org>
Subject: Re: [jakarta.ee-spec.committee] Jakarta EE 8 certification goal

 

I've added a few definitions to the document. They may be wrong; I put them in there because I get the feeling that my definition of what Specification Project means is different from yours.

 

In my email regarding goals, I started by defining what I thought are three different aspects of this process. In my mind, it was helpful to keep these separate.

• The development of the specifications themselves;
• The process of ratifying and promoting official specifications; and
• Certification of implementations of ratified specifications.

One big difference between the JCP and what we will do is, I believe, that we won't spin up an entirely new JSR/team for each version of the specification. In my mind, the Specification Project is an open source project in the sense that it is defined by the Eclipse Development Process (EDP). Team members come and go, but the project itself persists. That project is responsible for generating all releases of the specification.

 

Development of the Specification

 

The general process that Eclipse open source projects follows is this:

 

 

A project proposal defines a scope of work that (generally) persists for the lifetime of the project (the scope can be changed if there is good reason to do so). Each release cycle starts with planning. For some projects this planning is an informal list of issues; other projects are more rigorous (we can decide what level of rigour is required for a Specification Project). Milestone builds give the primary stakeholders an opportunity to review the work and provide feedback. The final release is what is delivered to the broad community.

 

The open source project team is responsible for generating the artifacts associated with the Specification as part of a release (as specified by the Eclipse Development Process. I believe that this minimally includes a document and API, along with pointers to an official reference implementation and TCK. 

 

Concerns regarding IP flows notwithstanding, I believe that the EDP almost competely covers this part of the process. You can, for example, think of the notion of milestone builds as early draft releases in the JCP sense. We can decide how or if the Specification Committee reacts to milestone builds: we could add a formal approval process, or make it more organic (the primary purpose of milestone builds is to generate feedback from primary stakeholders; the Specification Committee and implementors are among the stakeholders who can provide feedback to incorporate into a subsequent milestone build).

 

Ratifying

 

The Specification Committee, then, is responsible for ratifying and promoting the output of the open source project's final release as an official specification. By the time we get to the point that a Specification Project makes an official release, the committee (and vendors) should have consumed milestone builds and provided feedback, so that final ratification step should be relatively straightforward.

 

So, I think that the spec creation and ratification process looks a little like this:

 

The project proposal includes a scope, so getting the Specification Committee's approval seems pretty natural. 

 

Likewise, setting the plan at the beginning of a release cycle seems like something that the Specification Committee should get some say in. I tend to prefer a feedback loop model for milestone builds rather than formal approval (but am ready to be convinced otherwise). 

 

Strictly speaking, the PMC approves releases, but we may decide to give the Specification Committee some say here. The main role of the PMC in the release process is to ensure that the process has been followed correctly and that the project is operating according to the open source rules of engagement. 

 

Ultimately, the Specification Committee has to ratify (and promote) the specification.

 

In terms of coordinating the delivery of multiple specifications, our experience with the simultaneous release may provide some good answers. More on this later.

 

Certifying

 

The final part is the actual process of certifying implementations. For this, I mostly just have questions.

 

Thoughts?

 

I can provide an overview/primer of the EDP on the next call if there is interest.

 

Wayne

 

 

 

On Tue, May 8, 2018 at 10:05 AM, Richard Monson-Haefel <rmonson@xxxxxxxxxxxxx> wrote:

Thanks!

 

On Tue, May 8, 2018 at 8:40 AM Mike Milinkovich <mike.milinkovich@eclipse-foundation.org> wrote:

On 2018-05-08 8:15 AM, Richard Monson-Haefel wrote:
> Would it be possible to simply create a one page Jakarta EE 8 spec
> that says Jakarta EE 8 products have to conform to the Java EE 8
> Specification and than use the existing TCK to test and certify? I’m
> not clear on the legal aspects of that but if that is possible we
> could actually knock out Jakarata EE 8 quickly and move on to all the
> other decisions needed before embarking on Jakarta EE 9.

No, this would is not possible for exactly the legal issues you mention.
It has to do with how we pick up rights to the patents which have been
licensed via the JCP. There is no way to carry those licenses forward,
so what we are going to have to do is stand up "expert groups" (if
that's what we call them) that include as many of the companies and
individuals who worked on the original JSRs. At a minimum we'll be
looking for the "big three" patent holders (Oracle, IBM, Red Hat) to
join into those groups so that all essential claims to which they have
patents will be picked up by the new process. Otherwise we will be
releasing Jakarta EE 8 with no granted patent rights, and that would be
a big mistake.

My guess is that the above paragraph could spur about 20 emails
questioning every aspect of it. Please resist the temptation :) We are
working hard with the lawyers to figure all of this stuff out but there
is still a lot a moving parts. But getting the flows for patent rights
done correctly is very important, and is getting quite a bit of attention.

--
Mike Milinkovich
mike.milinkovich@eclipse-foundation.org
(m) +1.613.220.3223

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

--

Richard Monson-Haefel
http://twitter.com/rmonson
http://www.tomitribe.com
http://www.tomitribe.io

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

 

--

Wayne Beaton

Director of Open Source Projects

The Eclipse Foundation

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

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

_______________________________________________
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://dev.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee

--
Mike Milinkovich
mike.milinkovich@xxxxxxxxxxxxxxxxxxxxxx
(m) +1.613.220.3223