| [jakarta.ee-wg] Minutes from Jakarta EE Steering Committee Meeting August 28 |
|
Minutes of Jakarta EE Steering Committee Meeting August 28 Attendees: The minutes of the August 7 meeting and August 22 budget meeting were approved.Budget Update 1) Per the minutes of the Budget meeting August 22 (attached), next steps on the budget are as follows: During the Steering Committee meeting IBM stated it believes it will be able to support $300K/year for 3 years depending on the language, particularly the contingency on enabling evolution of the javax namespace discussed on August 22. - Assuming funding commitments are obtained, we would draft, review and vote on a Steering Committee resolution with the required funding levels. 2) We reviewed proposed membership fees distributed by Paul White. Discussed participant fees and intent to defer fees until 2020. General intent is that vendors must be a participant member in order to use the Jakarta EE brand (in addition to technical requirements). Updates on Oracle contributions The following projects were pushed to Eclipse repositories in the past week: Oracle continues to work on GlassFish contribution and contributions to be made under EDL licensing terms. Discuss Email re: Building Momentum for Jakarta EE (This email and Bill Shannon's follow-up email on spec process are attached) The content from the following email (in italics below) sent by Oracle prior to the meeting was reviewed. There was only time available to discuss the first two items. This proposal above and the tracking spreadsheet was reviewed and discussed, and was also reviewed/discussed at PMC (earlier in the day). PMC members requested time to follow up on this request. 2. Create a roadmap for definition of a specification process by the end of the year The email from Bill Shannon attached describing work items to complete the specification process was discussed. 3. Announce commitment to Working Group funding[Feedback on the preceding paragraph was received prior to the meeting from Richard Monson-Hafael and endorsed by Martijn Verburg and Mark Little.] "The last sentence troubles me because, in my mind, it implies that GlassFish has some special official status compared to other implementations. I would change the sentence "We expect Eclipse GlassFish sources will become the basis for implementations of Jakarta EE specifications." to read "We expect Eclipse GlassFish sources will become the basis for an implementations of Jakarta EE specifications." Notice that I added an and removed the plural from implementation." Legal Documents The Eclipse Foundation has received an updated TCK License Agreement proposal from Oracle. It will review with counsel this week. Marketing Committee Update (no time for discussion during the meeting) Marketing plan distributed. Several short term targets - e.g. end of Sept announcements of Eclipse GlassFish Java EE 8 cetrtification. Are we intending to announce on this date? We do not expect to be complete on this date.PMC Update (no time for discussion during the meeting) Any update from PMCRecruitment of new members; Elections (no time for discussion during the meeting) Planned Jakarta EE certifications (no time for discussion during the meeting)Open issue - will there be an additional PMC representative on the Steering Committee.
|
--- Begin Message ---
- From: will.lyons@xxxxxxxxxx
- Date: Wed, 22 Aug 2018 12:37:23 -0400
- Organization: Oracle Corporation
- User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:45.0) Gecko/20100101 Thunderbird/45.5.1
Draft minutes from Jakarta EE Steering Committee Budget Meeting on August 22
Attendees:
Fujitsu: Kenji Kazamura
IBM: Dan Bandera
Oracle: Will Lyons
Payara: Steve Millidge
Red Hat: Scott Stark
Tomitribe: Richard Monson-Hafael
Martijn Verburg
Ivar Grimstad (not present)
Eclipse Foundation: Mike Milinkovich
The purpose of the meeting was to discuss funding commitments from Strategic Members of the Jakarta EE Working Group. We referenced the draft minutes of the August 2 Budget Meeting below.
1) Oracle opened by saying it is prepared to commit to funding at the option 1 level ($300K/year) for three years.
2) Fujitsu abstained at this time. Kenji is prepared to initiate an approval request for funding at the option 1 level ($300K/year) for three years, but it may take several months to obtain internal approval and approval is uncertain. It is assumed that funding commitment would be contingent on resolution of the javax namespace requirement per the contingency statement below*.
3) IBM has not formally submitted an internal funding request. IBM had assessed funding at $150K (year 1), $300K (year 2), and $300K (year 3), and believed it was doable. IBM needs to go back to evaluate funding at the option 1 level ($300K/year) for three years. Funding commitment would be contingent on resolution of the javax namespace requirement per the contingency statement below*.
4) Payara can commit to funding at the option 1 level ($25K/year) for three years. Funding commitment would be contingent on resolution of the javax namespace requirement per the contingency statement below*.
5) Red Hat needs to get confirmation from Mark Little on approved funding levels. The request to Red Hat would be for funding at the option 1 level ($300K/year) for three years. It is assumed that funding commitment would be contingent on resolution of the javax namespace requirement per the contingency statement below*.
6) Tomitribe can commit to funding at the option 1 level ($25K/year) for three years. Funding commitment would be contingent on resolution of the javax namespace requirement per the contingency statement below*. Tomitribe would prefer a funding model which encourages contributions from other contributions as well - for example $5K/year. This question of how to encourage incremental funding from other members was discussed and will be revisited at Steering Committee. Tomitribe is willing to make the funding commitment above prior to resolution of this question.
7) LJC intends to run a crowdfunding campaign to support Jakarta EE. LJC believes a $5K contribution would be manageable in Year 1.
*Contingency statement: Commitment would be to year 1 funding and two more years at the option 1 level, with option to withdraw funding after year 1 if there is no progress on enabling evolution of the current Java EE 8 technologies, including Java EE 8 specifications and including javax namespace evolution (use of javax namespace for current specifications - no use of javax in net new specifications).
Eclipse Foundation: This process will result in a participation agreement - at some level if a WG/SC member cannot commit at the level required, then they will not be able to participate at this level. The Eclipse Foundation will attempt to be as flexible as possible on this point, and sensitive to internal budget processes of member organizations.
Next steps:
- We will follow-up on this topic specifically at next SC meeting. The primary request is to IBM and Red Hat to obtain the requested funding commitments.
- Assuming funding commitments are obtained, we would draft, review and vote on a Steering Committee resolution with the required funding levels.
- EF would draft a participation agreement based on the agreed funding levels, with the contingency statement referenced above.
On 8/6/18 9:46 PM, will.lyons@xxxxxxxxxx wrote:
Draft minutes from Jakarta EE Steering Committee Budget Meeting on August 2
( Note doodle poll for follow-up meeting week of August 20-27: https://doodle.com/poll/424g8efu9zzbiu8m )
Attendees
Fujitsu: Kenji Kazamura
The discussion focused on review of Mike Milinkovich's email sent on August 2 and appended below.
IBM: Dan Bandera
Oracle: Will Lyons
Payara: Steve Millidge
Red Hat: Scott Stark (joined towards end of meeting)
Tomitribe: Richard Monson-Hafael
Simon Maple
Ivar Grimstad
IBM, Fujitsu, Simon, Ivar felt Mike's email proposal was reasonable.
Oracle's feedback was that the steady-state budget should be closer to $1.5M. Will request input on budgets for similar initiatives in other foundations as comparisons for Mike's budget proposal.
Red Hat and Payara are concerned on the ability to execute based on lack of progress on legal matters. Would like to see a proposal to resolve the current roadblocks to evolving the javax namespace.
Payara and Tomitribe felt the overall magnitude of the budget felt large, but would like more input based on the expertise of the large vendors.
Tomitribe would like to see a plan for ramping up participant contributions.
Attendees agreed to review the proposal below within their organizations and be prepared to discuss these proposals during a meeting the week of August 20-27. A doodle poll has been opened to schedule this meeting.
https://doodle.com/poll/424g8efu9zzbiu8m
Will
On 8/2/18 9:49 AM, Mike Milinkovich wrote:
All,
For the Jakarta EE budget call today I would like to make the conversation more concrete than it has been up to this point.
- The Specification Process is in some disarray. So as of this moment, we cannot commit to a specific release date for innovative new Jakarta EE technologies in 2019. Given that, we think that it does not make sense to approach this budget conversation with any number higher than Option 1, as shown below. So that means a $1.5M target budget.
- Given the members around the table, the dues provided to use should total $1.0M and $1.2M, leaving us with a $450K to $250K gap that is going to have to be filled with additional recruitment. But until that recruitment happens, we have less than the anticipated budget to spend.
- Based on the above we (the EMO) will construct a budget that is a simple 50-50 split between headcount and program spend. But to do that will require to Steering and Marketing Committees to do more work on prioritization than they have done to date. This makes the Program Plan conversation more relevant, as we think that's the vehicle to drive the prioritization conversation.
- We will be looking for a three year commitment from the members in order to provide for the certainty we need to hire staff. This will require the development of a Jakarta EE WG participation agreement.
- Of course, all of the above will require each company to obtain internal budget approvals for the amounts.
Looking forward to our discussion.
Corporate Revenue
OPTION 1: Annual Fees $1.5M Target Budget
OPTION 2: Annual Fees $2.5M Target Budget
OPTION 3: Annual Fees $3M Target Budget
Annual Corporate Revenues greater than $1 billion
$300,000
$500,000
$600,000
Annual Corporate Revenues greater than $500 million but less than or equal to $1 billion
$200,000
$300,000
$400,000
Annual Corporate Revenues greater than $100 million but less than or equal to $500 million
$100,000
$200,000
$300,000
Annual Corporate Revenues greater than $10 million but less than or equal to $100 million
$50,000
$75,000
$100,000
Annual Corporate Revenues less than or equal to $10 million
$25,000
$25,000
$25,000
_______________________________________________ jakarta.ee-steering mailing list jakarta.ee-steering@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/jakarta.ee-steering
--- End Message ---
--- Begin Message ---
- From: will.lyons@xxxxxxxxxx
- Date: Mon, 27 Aug 2018 12:05:28 -0400
- Organization: Oracle Corporation
- User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:45.0) Gecko/20100101 Thunderbird/45.5.1
Hello -
We propose the following to build momentum for Jakarta EE, and would like to discuss these topics in the next Steering Committee meeting below.
1. Release Eclipse GlassFish and certify it as Java EE 8 compatible by Oracle CodeOne / EclipseCon Europe.
This effort will provide an implementation of Java EE and Jakarta EE that the Jakarta EE community can evolve. Oracle has invested a substantial amount of effort in this, and continues to do so, in order to achieve a shared goal we have discussed and agreed to as a group. This is an important milestone and Oracle remains committed to deliver it. However, contributions to this effort from other Working Group members would accelerate delivery, improve community collaboration, and facilitate transfer of technology ownership.2. Create a roadmap for definition of a specification process by the end of the year
Each of the EE4J projects have project leads identified. Each of the EE4J projects needs to be released and a task in the project’s issue tracker has been opened to track this activity. For example, see: https://github.com/eclipse-ee4j/servlet-api/issues/195
We would welcome project leads, or other committers, to take the initiative to:
• Review the release documents and prepare to release these projects, or recruit and encourage other community members to do so, and..
• Update the appropriate Jira issues reflecting your plans
• Let Ed and Dmitry know if you will take on responsibility for releasing the project in question
There has been some response on this recently and we'd like to continue the momentum. Dmitry has created a Google spreadsheet for tracking progress:
https://docs.google.com/spreadsheets/d/1e8inaprMOjnq04hU2o76egHhC8AF3-vNvqjRq6GR0eM/edit#gid=0
One requirement for completing definition of a spec process is execution of legal agreements between Oracle and the Eclipse Foundation. With support of our executive management, we are requesting acceleration of this process. We are asking our Legal team to set a target for delivery of a draft Trademark License Agreement. We will also request that once a draft is available that our counsels meet face to face regularly to resolve issues with agreements more quickly.3. Announce commitment to Working Group funding
However, most of the spec process can be defined independently of the above agreements. Bill Shannon will be sending a separate document detailing work items that we should address now, independent of the legal agreements. Ideally we define public milestones some of which are achievable by Code One / EclipseCon Europe. Please look for a note from Bill.
Assuming we collectively commit to a funding model, we should communicate this externally. We expect to make progress on this topic in the next Steering Committee meeting.4. Demonstrate successful execution of the contributed TCKs
Java EE 8 certification of Eclipse GlassFish will be based on existing Oracle TCK binaries.5. Define distributed ownership of Jakarta EE technology areas and directions
We have stated that a next step following Java EE 8 certification of Eclipse GlassFish would be Jakarta EE 8 certification of Eclipse GlassFish. This step depends on definition of a Jakarta EE 8 specification (discussed in #2 above), and successful execution of the contributed TCKs, which we intend to become the Jakarta EE 8 TCKs, on Eclipse GlassFish.
We would like affirmation from this group that Jakarta EE 8 certification of Eclipse GlassFish, including demonstration of successful execution of the contributed TCKs, remains a shared goal. Oracle will drive this overall effort, but requests that project leads, with contribution from other Working Group members and other community members, take ownership for driving successful execution of the contributed TCKs in their area.
Oracle regards ownership of technology areas as a shared responsibility going forward, not as an Oracle driven activity as in Java EE. We would like to drive a process where we move from the Oracle-driven project leadership model that we have today to a model where project leadership is more distributed across the Working Group and the community, and where project leads define directions for individual projects.6. Commit to Code One/ECE messaging
We propose scheduling a meeting in September to review the project list and more clearly demonstrate distributed project ownership and project direction, with the intent to publish for the community by Code One. As part of this effort recommend identifying those technologies that we expect to invest in and evolve, and those we do not plan to invest in.
Oracle proposed the following Code One messaging. We believe that the above can be used to augment the messaging below. We request your support to these messages or some other set of messages.Thanks
Announcing Eclipse GlassFish.
GlassFish contributions to Jakarta EE are complete and Eclipse GlassFish is certified as Java EE 8 compatible [adjust statement based on actual level of completion]. We expect Eclipse GlassFish sources will become the basis for implementations of Jakarta EE specifications.Java EE TCKs are open sourced.
The Java EE 8 Technology Compatibility Kits have been contributed and are available in Open Source. We expect these to be the basis for Jakarta EE 8 compatibility tests for branding of multiple independent implementations of Jakarta EE specifications.We [Oracle and other WG members] are committed to Jakarta EE.
We [Oracle and other WG members] remain committed to enabling evolution of the Java EE 8 technologies, including evolution of the javax namespace, in Jakarta EE specifications for cloud native Java. [Hope to identify specific milestone]. We [Oracle and other WG members] have committed to funding this effort at the Eclipse foundation.We [Oracle and other WG members] will leverage Jakarta EE.
We [Oracle and other WG members] intend to leverage Jakarta EE technologies and cloud native Java in its product and service offerings. [Each WG member may have its own announcement that will...] leverage Jakarta EE and/or Eclipse GlassFish technology, and/or will support Java EE 8, Jakarta EE 8 and evolution of Jakarta EE.
Will
--- End Message ---
--- Begin Message ---
- From: Bill Shannon <bill.shannon@xxxxxxxxxx>
- Date: Mon, 27 Aug 2018 12:06:25 -0700
- Delivered-to: jakarta.ee-spec.committee@xxxxxxxxxxx
- List-archive: <https://dev.eclipse.org/mailman/private/jakarta.ee-spec.committee>
- List-help: <mailto:jakarta.ee-spec.committee-request@eclipse.org?subject=help>
- List-subscribe: <https://dev.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee>, <mailto:jakarta.ee-spec.committee-request@eclipse.org?subject=subscribe>
- List-unsubscribe: <https://dev.eclipse.org/mailman/options/jakarta.ee-spec.committee>, <mailto:jakarta.ee-spec.committee-request@eclipse.org?subject=unsubscribe>
- User-agent: Mozilla/5.0 (X11; SunOS i86pc; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
I believe our goal is to define an Eclipse spec process that can be used by other non-Jakarta EE projects, as well as a customization of that process for Jakarta EE. I expect the Jakarta EE spec process document to cover two main items: 1. The "mechanics" of moving a spec through the process. 2. Technical requirements on specs that use the Java trademark. #1 would be largely identical to the Eclipse spec process. #2 would clearly be part of the Jakarta EE customization of the spec process. For #1, I'm imagining a document similar to the JCP process document https://jcp.org/en/procedures/jcp2 or the OASIS Technical Committee Process https://www.oasis-open.org/policies-guidelines/tc-process-2017-05-26 that describes at least: - how a spec enters the process - what steps a spec must take as it moves through the process - how a final spec is approved - the role of the Specification Committee in the above - who votes when and how on the above items and how votes are counted - what happens when a vote fails - how to transfer leadership of a spec/implementation/TCK - how the spec process itself evolves The Eclipse Development Process may provide a framework for much of the above, which should certainly accelerate producing a complete spec process document. Clearly Oracle will provide #2. I'm expecting it to be incorporated into the spec process by addition of a rule something like this: Any of the specification projects that make use of the Java trademark (listed in Appendix A) must follow the additional rules and restrictions listed in Appendix B. An early draft of proposed rules and restrictions is available here: https://docs.google.com/document/d/16OttV-FHv-OtSYwa1H74dtQatO4a-9E1QnP9LYyTBsY/edit This document is out of date but gives you a general idea of the sorts of rules we expect to impose on projects that use the Java trademark. The spec committee has spent a lot of time talking about items that I *don't* think need to be part of the spec process document. We should, however, decide whether they need to be required rules for a Jakarta EE customization of the Eclipse spec process, or whether they are merely conventions that we recommend that EE4J projects follow. These include: - Java package names for new specs - Maven group IDs - Version numbers - TCK appeals process There are several other items that are related to the spec process but I don't think are actually part of the spec process: - the spec license - rules for use of the Jakarta EE brand Do we all agree that producing a specification process document as described above is the top priority for the Specification 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
--- End Message ---