Replying to my own email.
A few additional points on my thoughts on some gates for the picture.
- Projects can be proposed at the EE4J level by anybody using standard Eclipse rules with approval of the EE4J PMC.
- Project can only propose to the spec committee if they produce the 4 required specification process inputs (API, RI, TCK, Spec doc)
- Specification (and project) can only be included in a profile if it satisfies any profile requirements for internal consistency.
My thoughts are these gates allow freedom to innovate at the EE4J level while also ensuring projects reach a certain level of maturity and internal consistency to make it into a profile. This protects
vendors from having to implement immature or not well integrated specifications to achieve the compatibility mark and provides a feedback loop to the individual projects to drive some profile level consistency.
Thoughts?
Steve
From: jakarta.ee-spec.committee-bounces@xxxxxxxxxxx <jakarta.ee-spec.committee-bounces@xxxxxxxxxxx>
On Behalf Of Steve Millidge (Payara)
Sent: 09 May 2018 13:03
To: Jakarta specification committee <jakarta.ee-spec.committee@xxxxxxxxxxx>
Subject: Re: [jakarta.ee-spec.committee] Jakarta EE 8 certification goal
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@xxxxxxxxxxx>
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).
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.
The final part is the actual process of certifying implementations. For this, I mostly just have questions.
I can provide an overview/primer of the EDP on the next call if there is interest.
On Tue, May 8, 2018 at 10:05 AM, Richard Monson-Haefel <rmonson@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxx
(m) +1.613.220.3223
_______________________________________________
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
_______________________________________________
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
--
Wayne Beaton
Director of Open Source Projects
|
