| Re: [jakarta.ee-wg] Approval announcemens |
> On Jun 15, 2019, at 5:13 AM, Oliver Drotbohm <ogierke@xxxxxxxxxx> wrote: > > Thanks everyone for chiming in. Thanks again for the open questions. I'm going to provide a ton of data below. I don't want that to be perceived as in any way diminishing or rebuking your feedback. It's all valid. There is publicly available information, but we have a long way to go to get the convenience factor way way up. We have further to go in advertising plans before they are final and providing more opportunities for feedback. In acknowledgement of this shortcoming, I've taken the time to grab the related chunks of the meeting minutes in efforts to help make the thought process more visible. > So I understand that apparently – nobody seems to know when or where exactly – a decision has been made. A decision that should've been guarded by dedicated requirements if we had followed the self-implied JakartaEE process. Shouldn't that decision then not be formally documented visible to everyone interested? I didn't mean to imply no formal decision was made ever, just no discussion recently. Looking at the meeting minutes again months later, I can see the status change. Otavio is independent as of May, so agreement delays on the Tomitribe side are no longer holding up NoSQL. Sort side note, our delays are tied to 1) ensuring Apache projects like TomEE can be on the future jakarta.ee certified list even though Apache is not a member of the Jakarta EE Working Group and 2) attempting to get them on the Jakarta EE Working Group if possible. There is no strong opposition, it's just with all the Java trademark legal issues this one has taken a back seat. It's 90% resolved now. Anyway, enough on that. Here are the minutes. Below is any mention of NoSQL in either the Steering, Specification or Marketing Committee in chronological order. The official vote was the "RESOLVED" text in the November 14, 2018 Specification Committee meeting. ---- https://jakarta.ee/meeting_minutes/steering_committee/minutes-july-31-2018.pdf Mike M: I would like to propose that we rethink our approach in order to deliver on the elements of Jakarta EE that we can as soon as possible. A couple of key concepts would include: 1. We decide as a group that any product which achieves "Java EE 8" certification can also be labeled as "Jakarta EE 8" certified. The Jakarta EE trademark and logo is our property. We can decide how it is used. 2. We narrow the focus of version 1.0 of the Jakarta EE spec process to focus on new specifications, rather than migrating the existing Java EE ones. That means that while Oracle is definitely involved, there is far less complexity related to their interests in protecting the Java trademark via the existing spec names and javax namespace. So instead of focusing on some very complex migration issues, let's focus instead on creating a spec process that would be attractive to MicroProfile, and JNoSQL, and the like. It seems unlikely that in the short term we are going to have the permissions that will allow us to evolve the Java EE 8 platform. So if we're going to demonstrate any ability to innovate it is going to have to come from other sources. ---- https://jakarta.ee/meeting_minutes/steering_committee/minutes-august-7-2018.pdf With the above in place, our new plan of record would be to: 1. Release Eclipse Glassfish 5.1 certified as Java EE 8 compatible, and labeled as Jakarta EE 8 certified as well by the end of September. 2. By <<insert date here>> release a Jakarta EE 9 specification which is [Java EE 8] + [MicroProfile | JNoSQL | ??]. We would avoid the entire concept of backwards compatibility with Java EE specifications by simply saying that if a product is certified as Java EE 8 certified and it passes the TCKs for the additional specifications, it can be certified as Jakarta EE 9 compatible. Note that I think this means that no changes whatsoever will be possible to the javax namespace. We could discuss whether some innovation could occur within Jakarta's namespace although that would not be backwards compatible, which is obviously an issue. ---- https://jakarta.ee/meeting_minutes/steering_committee/minutes-august-21-2018.pdf It was pointed out that significant progress can be made on the specification process independent of the legal issues discussed above. The example of JNoSQL was cited, where there is no dependency on the legal issues described above. ---- https://jakarta.ee/meeting_minutes/specification_committee/minutes-specification-august-29-2018.pdf Create a plan to deliver a draft Specification Process for CodeOne/EclipseCon (30 minutes) a. Notes from meeting discussion: i. The group discussed what our deliverable should be for this timeframe. The general consensus was: 1. Provide a draft specification process for community feedback by CodeOne/EclipseCon. The goal is to use the events to communicate with community members and maximize community awareness and feedback. 2. Recruit our first candidate spec willing to announce their interest in using the Jakarta EE spec process. Eclipse JNoSQL was discussed as one potential. ---- https://jakarta.ee/meeting_minutes/specification_committee/minutes-specification-october-17-2018.pdf Should we use the EF Specification Process the first spec “Jakarta EE NoSql” ○ https://projects.eclipse.org/proposals/jakarta-ee-nosql ○ Concerns raised since the spec process is not fully defined ○ we’ll go through the process as is fro this spec, with the request to run through the process again once it is final. ---- https://jakarta.ee/meeting_minutes/marketing_committee/minutes-marketing-november-1-2018.pdf Spec Process draft received no feedback. Looking at creating publicity around current status and when JNoSQL is successful through spec process. ---- https://jakarta.ee/meeting_minutes/specification_committee/minutes-specification-november-14-2018.pdf ○ We will use Jakarta EE NoSQL to test EF Spec Process and do customization if necessary to created Jakarta EE Spec process. ■ As we work through the process with Jakarta EE NoSQL, we will capture notes and evolve a draft of the Jakarta EE Specification Process. ○ RESOLVED: Jakarta EE NoSQL will be allowed to begin work using the draft EF Spec Process, assuming the team is aware and prepared for the risks associated with working through draft process ■ Mike Denicola moved ■ Dan Bandera second ■ No objections ○ Vote on Creation review on Jakarta EE NoSql - voting from the Spec Cmte ■ We will use of jakarta.ee spec mailing list ■ Period, email subject line...will clearly indicate that a VOTE is required ■ Jakarta EE NoSQL Project proposal link https://projects.eclipse.org/proposals/jakarta-nosql ---- https://jakarta.ee/meeting_minutes/specification_committee/minutes-specification-november-28-2018.pdf ○ Jakarta EE NoSQL project status ■ Creation review is done ■ provisioning is next step; we are waiting on : ● Board approval of the new IP policy ● Agreements need to be in place (MCCA and WGPA) for project lead/primary committer (Tomitribe) ● Agreements for other committers (being pursued by the EF Membership Team via separate channels). ● Wayne / Tanja to follow up with EF Membership Team to get in touch with Tomitribe ○ Proposal to make Jakarta EE NoSQL go through the full Jakarta EE Specification Process once it’s defined and adopted by the Specification Committee. General agreement in principle, will sort out details as we develop the process. ○ Werner - in 2 weeks, Dec 12th, to provide an update on Jakarta EE NoSQL ---- https://jakarta.ee/meeting_minutes/steering_committee/minutes-december-11-2018.pdf It was noted that JNoSQL cannot move forward until the applicable Participation Agreement, Member Committer Agreement is in place. ---- https://jakarta.ee/meeting_minutes/specification_committee/minutes-specification-december-12-2018.pdf Jakarta EE Spec process and Jakarta EE NoSQL project ○ based on EFSP v1.0, but not necessarily the same ■ Example: Jakarta EE Specification Process v1.0 ○ We will use Jakarta EE NoSQL to test EF Spec Process and do customization if necessary to create Jakarta EE Spec Process.By going through the process with Jakarta EE NoSQL, we will capture notes and evolve a draft of the Jakarta EE Specification Process. ○ Jakarta EE NoSQL provisioning is next step; we are waiting on : ■ Board approval of the new IP policy (DONE) ■ Agreements need to be in place (MCCA and WGPA) for project lead/primary committer (Tomitribe) ■ Agreements for other committers (being pursued by the EF Membership Team via separate channels). ■ This is expected around late Q1 2019 ○ The equivalent of a JCP maintenance review needs to be addressed (additional notes Nov 28th) ■ Wayne to author a draft. Based on that work we can decide whether it is part of the Jakarta EE Specification Process or a future version of the EFSP. ○ We need a “Dials and knobs” document (possibly an FAQ) that details how a Working Group might extend the EFSP. ■ Suggestion to describe what is immutable Werner - Dec 12th to provide an update on Jakarta EE NoSQL ○ Nothing to add. We’re waiting on documents to be signed. Hopefully we’ll have what we need in 2019Q1. There is effectively zero chance that we will be able to bootstrap NoSQL in 2018. ---- https://jakarta.ee/meeting_minutes/specification_committee/minutes-specification-december-19-2018.pdf [identical status reported] https://jakarta.ee/meeting_minutes/specification_committee/minutes-specification-january-9-2019.pdf [identical status reported] https://jakarta.ee/meeting_minutes/specification_committee/minutes-specification-january-16-2019.pdf [identical status reported] ---- https://jakarta.ee/meeting_minutes/specification_committee/minutes-specification-february-13-2019.pdf We discussed learning about what we want to specialize by doing. We’re in a holding pattern on Jakarta NoSQL. Arjan suggested that we push forward with JSF. We need to determine what we need to make this happen in consideration of the larger plan to move us forward on Jakarta EE. Wayne agreed to chart out the path and send it to the group. Ivar made a similar offer regarding the MVC specification. ----
Attachment:
signature.asc
Description: Message signed with OpenPGP