Working Group Standalone Proposal

[John Clingan]

It's taking longer than planned, but expect a document published Monday. Of course, it will be a working draft with some issues to address but that we can all provide input on.

[Amelia Eiras]

Sounds wonderful John. Thank you for getting the ball rolling on this. 

Once share, please add me as one of the editors of the document. As stated on this week's Community call, I will prioritize helping on the document. Cheers! 

[Amelia Eiras]

John, 

The off-weeks MPWG hangouts are not scheduled yet. FYI as next one is tomorrow, twice per month. 

Thank you for dealing with this, should you need help, I am happy to create those events, just do let me know. The MPWG 1hr hangout schedule re-starts under new task on: 4/7 through 6/30 --- which is the soft-tentative deadline as mentioned on last week's Community hangout. 

Cheers, 

On Friday, April 3, 2020 at 1:57:56 PM UTC-7, John Clingan wrote:

[John Clingan]

I JUST noticed that before my last meeting. We only scheduled for 3 months. Adding 3 more months. Fixing now.

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/e397f3c5-c3d2-43c9-8c4c-1d7aa1dd429f%40googlegroups.com.

[Amelia Eiras]

awesome! :) and better b/c it makes no sense to schedule stuff without proper tracing/. now there is tracing so new one re-starts. it is great. 

See you tomorrow and thank YOU John, you are the best!

Amelia Eiras 

twitter.com/ameliaeiras

Tribe: http://tomitribe.com      https://tribestream.io   

OSS:  http://microprofile.io     https://jakarta.ee

You received this message because you are subscribed to a topic in the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/G5WZvF0wZuY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to microprofile...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/526E3F9B-873A-46D1-A9A6-05A5861217FA%40redhat.com.

[John Clingan]

OK, here we go. Notes:

• David Blevins, John Clingan, Kevin Sutter, and Scott Stark got together Friday and Monday to prep something for the Live Hangout Working Group Discussion.
• This is a Working Group Charter Proposal
• This proposal is a draft. Let's get a lot of feedback, quickly I hope. We have a 4.0 release in the making :-)
• Some verbiage is boilerplate, some is specific to MicroProfile. All verbiage is open to feedback!! As Mike Milinkovich mentioned, AsciiDoc and Sparkplug are existing examples.

On Friday, April 3, 2020 at 1:57:56 PM UTC-7, John Clingan wrote:

[Ondro Mihályi]

Hi,

The proposed charter suggests that there's only a single Combined Steering/Specification Committee but the table in the Membership summary section mentions separate steering and specification committees. Shouldn't the table only mention the single steering/specification committee?

The Membership table also mentions a marketing committee but the committee isn't mentioned in the Governance section. Is the marketing committee covered by some other Eclipse document or it should be added to the Governance section?

Ondro 

[John Clingan]

Thanks for the quick feedback, Ondro!

Eclipse Foundation Spec Working Groups require a steering committee and a spec committee. We call out the fact that we have them, but this proposal combines them. So, any member of one is a member of the other, and we then refer to it as "Combined Steering/Specification Committee". It's the way we've been working with MicroProfile to date. Less process with organizational simplicity. Thanks for pointing it out though, we can review the wording.

On the marketing side, that may be an oversight as we worked on the doc sequentially. While we will continue to have our awesome marketing group, we decided not to embody that in the working group definition. Again, we can review the wording.

[Ondro Mihályi]

I understand now, John.

This should be explained right in the document, there's nothing that explains how this combined committee works and that it replaces the 2 committees. I'll add suggestions to the document how to improve this. 

[John Clingan]

I see the edits. I'll review. Thx for taking the initiative!

[John Clingan]

Regarding the WG Proposal thread on implementation vs innovation first, we have some history here. One of the reasons that MicroProfile was created was because each vendor was introducing microservices-related innovation in unique, non-compatible ways. We thought we could collaborate on those innovations. We then formed MicroProfile as a means to address that (among other things).  What is important to note is that this was basically implementation first. Innovations appeared in our runtimes before they appeared in specs.

Personally, I'd prefer to avoid the EJB 1.x debacle and at least have some volume of experience before creating a specification. I'm curious as to which existing MicroProfile specifications are not based on industry experience. If I think of Configuration, there are countless implementations available that we learned from. Fault Tolerance had existing successful implementations in the market (and I think based on Failsafe to a large degree). Ditto Metrics (dropwizard).

Are we dealing with semantics in the thread when comparing "implementation first" and "experiment and innovate"?

On Friday, April 3, 2020 at 1:57:56 PM UTC-7, John Clingan wrote:

[David Blevins]

There's a long thread on the "implementation first" comment I made.  Despite the comments appearing different, I actually think when the rubber hits the road we all tend to behave in unison.

Let me give a real-world example and everyone can chime in on where you sit.  If we all lean the same way, it's just a matter of finding the right words to describe our appetite.

The Open Tracing people have discontinued their work and have restarted their effort as Open Telemetry with a first release of the specification expected (IIRC) some time this summer.  At this moment the industry value of their effort is a complete unknown.

Now the question is what do we do here together as a community?

  a) Begin shifting some attention off of Open Tracing and towards Open Telemetry.  We team up to understand what's going on in Open Telemetry, how it impacts us and what kind of response there should be from us.  One of us begins to feel very confident in how this should be approached and starts a sandbox initiative to address the topic.  Others join in and drafts of the spec are created while some of us work on implementations.  We release something for early feedback, but it is not yet ready to be part of the MicroProfile platform spec and is therefore not included.  There are no plans to include it in the platform until Open Telemetry and our Java bindings for it show some value in the industry.  This may be months or years or never.  We are however, collaborating together and playing a role in seeing if Open Telemetry has some value and if it does, we're first to market.

 b) We shifting some attention off of Open Tracing and towards internal efforts on Open Telemetry.  We work separately to understand what's going on in Open Telemetry, how it impacts us and what kind of response there should be.  We individually implement separate and uncoordinated efforts to address the space.  We gather feedback from our customers and users.  After some months or years once Open Telemetry and our or anyone's implementations have shown some value we start a specification effort.  Those other implementations are first to market and may include efforts from Spring, Micronaught and others who are implementations, not standards.  Our MicroProfile branded effort around Open Telemetry therefore happens after those implementations have proven success with customers.

If neither A nor B fit how you view things, feel free to give another recommendation on how MicroProfile should or should not innovate in the industry with regards to something like Open Telemetry.

My answer is:

 - We've always leaned very heavily towards B in Java EE and I it does have significant value and do not want to stop, but I see MicroProfile as the way we can lean more heavily towards A.  We don't need to go crazy, but I do want to push the limits of our comfort zone and see if we can work together earlier and arrive at B much much sooner.

-- 

David Blevins

http://twitter.com/dblevins
http://www.tomitribe.com

310-633-3852

On Apr 3, 2020, at 1:57 PM, John Clingan <jcli...@redhat.com> wrote:

It's taking longer than planned, but expect a document published Monday. Of course, it will be a working draft with some issues to address but that we can all provide input on.

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/35762c39-4631-4846-a067-5078252916d6%40googlegroups.com.

[Reza Rahman]

David,

Your view of the core value proposition of MicroProfile vis-a-vis Java EE coincides exactly with mine. It should be a responsive, less conservative and faster moving specification development effort to meet the needs of a rapidly changing technology space and Java developers that at least to some extent care about a somewhat vendor neutral set of APIs targeting that rapidly changing space.

Reza Rahman
Jakarta EE Ambassador, Author, Blogger, Speaker

Please note views expressed here are my own as an individual community member and do not reflect the views of my employer.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/D19AEF07-E215-4399-A714-A490F2C5CF3C%40tomitribe.com.

[John Clingan]

FYI, I've created a document to help us track action items for the transition to a working group. For now a google doc is a good forum given the dynamic context we are in, but I hope shortly we can scrap it and move these into github issues on the microprofile and microprofile repositories.

https://docs.google.com/document/d/10C_n9qK9yYLFcA7PtAHWmu2hjz1B8eQ-rbih3Bc6jsQ/edit

Note: Everyone has edit rights.

On Friday, April 3, 2020 at 1:57:56 PM UTC-7, John Clingan wrote:

[Emily Jiang]

+1 David! Your option A is exactly what I expressed re my comment on the WG. Well said, Reza!

I would like to see Open Telemetry execise to collaborate in MP not in other spaces. Collaboration in MP makes MP active and vibrate, not precooked and merely namespace changes.

The worry with Option B is that the experiment might not never come back to MP and then leads to another Spring like community.

Emily

To unsubscribe from this group and stop receiving emails from it, send an email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/35762c39-4631-4846-a067-5078252916d6%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.

To unsubscribe from this group and stop receiving emails from it, send an email to microp...@googlegroups.com.

[Mark Little]

Hi David.

Great email and a good example of one specific aspect where MP should divert from "traditional" efforts. On this case I would say option A. However, let me now give two other scenarios which I referred to in the WG doc and for which there seemed to be no agreement. These also wouldn't call into your A or B so easily but maybe I'm wrong:

• Scenario 1: someone has a great idea for something in the microservices space for which no implementation yet exists anywhere. They may even be able to convince others that this is The Next Big Thing. In this scenario MP is not the place to go just yet. Those people and maybe vendors should create a new open source project (well I suppose it could be closed source) and see where that takes them. Maybe they're right and it gets massive adoption. Maybe it even spawns copies which take their original ideas in slightly different directions. At that stage they and their communities may well want to try to agree some standard Java APIs for the underlying implementation and that's where MP could come in.
• Scenario 2: there are a number of successful efforts (implementations) in the area of something the MP community feels it wants to try to create a standard API around. Maybe the implementations are closed source, open source, in a variety of languages etc. However, a critical mass of the MP community feels it's worth trying to pull this into MP for Java developers so they can benefit from portability, say. No de facto standard API exists already. No formal standard exists or at least not in a way that Java developers can consume. This is definitely where MP could come in and possibly also encourage a collaborative implementation effort (open source, of course).

Both of these scenarios are examples of where implementation efforts and experience eventually drive MP API/spec/TCK work. Your original example around OpenTelemetry is likewise but by it's nature presumes a different starting point in the cycle of an idea through to MP. I think it is important we don't presume MP cannot encourage idea formation but it certainly should not be the place where those ideas are then fleshed out and tried on users. Or put another way, MP is not a replacement for a good open source project where people can kick the tyres on implementations, APIs etc. MP should not attempt to be the proving group for the underlying ideas behind specific implementations but an environment where different groups, vendors, researchers etc. can come together and agree on APIs using experience derived from implementations which exist elsewhere.

BTW, whilst I think this is a very useful discussion to be had, we shouldn't let it get in the way of finalising the WG proposal.

Note, I'm also officially on holiday at the moment so further responses may well be delayed for a week or so.

Mark.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/D19AEF07-E215-4399-A714-A490F2C5CF3C%40tomitribe.com.

[John Clingan]

This is an interesting discussion.

I hadn't really been thinking of David's scenario. Open Telemetry is based on existing experiences (OpenCensus and OpenTracing) and has some degree of compatibility (bridge?) with OpenTracing. +1 with Option 1 for this use case. Wrapping an API around OpenTelemetry, especially with our experience in OpenTracing isn't as overly risky as Mark's scenario 1.

What I had been thinking of in the context of "implementation first" is Mark's scenario 1. Something new and innovative but with no existing implementation. IMHO, go off and implemented elsewhere, prove the idea has real-world merits, and then we can create a spec around it. I think even here there is a spectrum, though. New and innovative could mean "no direct correlation to existing ideas". New and innovative could also mean "an extension of existing ideas". For the former, I'd be really worried about doing that in MicroProfile. For the latter, less worried but IMHO "it depends on the extension".

For Mark's scenario 2, I think this is what we have done with (for example) Metrics, Config, and Fault Tolerance. This has been very successful for MicroProfile. It's clear we didn't always get the APIs right the first time and we have iterated to get it to a "proper" state, and that is what MicroProfile means by iteration.

The question remains how to word this in the charter (based on overall feedback). Perhaps tomorrow during the Hangout.

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/35762c39-4631-4846-a067-5078252916d6%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile+unsubscribe@googlegroups.com.

[Emily Jiang]

The way I understood "implemention first" is that a spec cannot be released unless there is an implementation and passed all of its TCKs.

As for the scenario 1 in Mark's email, I don't see a problem with collaborating the new idea in MicroProfile space and release after the group has done the implementation. I don't understand why we need to limit MicroProfile only picking up existing technologies. In 2019, we have only one new spec being accepted. I don't see the problem there are overwhelming specs being proposed or accepted.

Emily

To unsubscribe from this group and stop receiving emails from it, send an email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/35762c39-4631-4846-a067-5078252916d6%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.

To unsubscribe from this group and stop receiving emails from it, send an email to microp...@googlegroups.com.

[David Blevins]

Had this thought after our hangout.

What we currently have written is a 2-to-1 ratio of corporate vs committer member and discussion on who the 1 can be (can they be employed by a corporation who is a member).  Either way you cut it, this still has flaws.

What if a specification vote was considered passed if it passes both a super-majority of corporate members and a super-majority of committers members?

For those who want context on why we need corporate votes, it's largely because of the patent protection that comes from having a company on official, undeniable record saying "we agree to this spec" which reinforces the already-existing patent protection baked into the various agreements.  It's very difficult to be on record one day agreeing to a spec then the next day suing over patent infringement.  The more official it is, the better -- a non-technical judge and jury need to "get it" unambiguously.   Our current status where there is no official company voter and therefore no official record is part of what we need to fix.

The question is really how to add that in without greatly changing the dynamics of our community which has so far been committer-lead.  This seems like one possible.

-- 

David Blevins

http://twitter.com/dblevins
http://www.tomitribe.com

On Apr 3, 2020, at 1:57 PM, John Clingan <jcli...@redhat.com> wrote:

It's taking longer than planned, but expect a document published Monday. Of course, it will be a working draft with some issues to address but that we can all provide input on.

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.

[m.reza.rahman]

I think it is very important for MicroProfile to be seen as a place to bring innovation in whatever initial state it is in if someone desires to go the eventual standadization route in the Java microservices space. This is perhaps the most important gap the initiative still addresses.

Reza Rahman

Jakarta EE Ambassador, Author, Blogger, Speaker

Please note views expressed here are my own as an individual community member and do not reflect the views of my employer.

Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/c5377203-9127-4bc8-827b-99332973cfd5%40googlegroups.com.

[Emily Jiang]

+1 Reza! We need to focus on the microservice gap/problem instead of focusing on whether a solution has been available already and then talk about in MicroProfile. This is pretty much we settled during MP hangout meeting today.

Back to David's question:

What if a specification vote was considered passed if it passes both a super-majority of corporate members and a super-majority of committers members?

My understanding is that corporate member and committer memebers are mashed together, no distinction. The super marjority applies to the total of corporate and committer members.

e.g.

A WG:  10 corporate members and 5 committer members (2:1 ratio)

For a specification vote to pass: 10 (2/3 of voters) votes and 8 (over half voters) postive votes

My 2cents.

Emily

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/c5377203-9127-4bc8-827b-99332973cfd5%40googlegroups.com.

[Paul Buck]

Something to keep mind here regarding the 2-to-1 ratio of corporate vs committer members in the combined Steering & Spec Committee. If there are 4 (or 5) corporate participant members then there would be spots for 2 committer reps on the committee. Applying the rule in the Eclipse bylaws that you can never have more than 1/2 of the elected committer reps coming from one company says that the 2 committer reps must be from different companies. 

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/6074E7E1-97ED-49B9-98B7-F3B8D4F40C18%40tomitribe.com.

[Steve Millidge]

However my concern is we also have 2 companies which are from the same corporate group. Therefore on those maths we could have 4 committee members out of 6 effectively from the same company.

[John Clingan]

Thanks for the heads up Paul.

On Wednesday, April 15, 2020 at 10:06:07 AM UTC-7, Paul Buck wrote:

Something to keep mind here regarding the 2-to-1 ratio of corporate vs committer members in the combined Steering & Spec Committee. If there are 4 (or 5) corporate participant members then there would be spots for 2 committer reps on the committee. Applying the rule in the Eclipse bylaws that you can never have more than 1/2 of the elected committer reps coming from one company says that the 2 committer reps must be from different companies. 

On Tue, Apr 14, 2020 at 3:36 PM David Blevins <dble...@tomitribe.com> wrote:

Had this thought after our hangout.

What we currently have written is a 2-to-1 ratio of corporate vs committer member and discussion on who the 1 can be (can they be employed by a corporation who is a member).  Either way you cut it, this still has flaws.

What if a specification vote was considered passed if it passes both a super-majority of corporate members and a super-majority of committers members?

For those who want context on why we need corporate votes, it's largely because of the patent protection that comes from having a company on official, undeniable record saying "we agree to this spec" which reinforces the already-existing patent protection baked into the various agreements.  It's very difficult to be on record one day agreeing to a spec then the next day suing over patent infringement.  The more official it is, the better -- a non-technical judge and jury need to "get it" unambiguously.   Our current status where there is no official company voter and therefore no official record is part of what we need to fix.

The question is really how to add that in without greatly changing the dynamics of our community which has so far been committer-lead.  This seems like one possible.

-- 

David Blevins

http://twitter.com/dblevins
http://www.tomitribe.com

On Apr 3, 2020, at 1:57 PM, John Clingan <jcli...@redhat.com> wrote:

It's taking longer than planned, but expect a document published Monday. Of course, it will be a working draft with some issues to address but that we can all provide input on.

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/35762c39-4631-4846-a067-5078252916d6%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile+unsubscribe@googlegroups.com.

[John Clingan]

FYI to all, I had an AI from the live hangout to start this in a separate thread, but I kind of like it here. It fits this thread's topic and this thread isn't unwieldy yet.

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile+unsubscribe@googlegroups.com.

[Kevin Sutter]

Steve,

> However my concern is we also have 2 companies which are from the same corporate group.

Although I can understand the source of your concern, I can guarantee you that these two companies have their own independence and views and agendas...  ;-)  Seriously, we really are operating as two separate companies.  Of course, if this barrier changes down the road, then our combined participation across all of the Working Groups (Jakarta EE, MicroProfile, etc) will need to be re-evaluated.

Also, the current definition of an Eclipse Working Group doesn't preclude this participation by merged companies.  We had to walk through all of this as soon as the merger was accepted.  At the Eclipse Board level, we were reduced to a single combined Vote.  The primary participant is from RH, with the deputy from IBM.  There were no provisions to do this reduction at the Working Group level.  If this is a concern, then somebody should raise it as a formal request to the Eclipse Foundation.  But, as I said, this goes beyond just the MicroProfile WG proposal.  We're not proposing anything unique in this particular area of the MP charter as compared to the Jakarta EE charter.

Thanks,

Kevin

[Kevin Sutter]

Emily,

I agree with your description of the voting structure.  Thanks for laying out a specific scenario as part of the reply.

-- Kevin

[John Clingan]

Emily, I agree with that characterizations for general vote makeup. Does this apply to annual(?) committer elections? All members vote on committer members, not just committer members vote on committer elections? This is my understanding, just wanna double-check.

Emily, in the charter proposal voting section, specification adoption ...

... must be approved by no less than two-thirds (2/3) of the representatives in Good Standing represented at a committee meeting at which a quorum is present.

We can discuss this more later, though. I'd like to focus on committee membership.

[Amelia Eiras]

where do we stand with the 2/3 corporate vote & 2/3 committers vote to keep the balance on classes?

I thought we were not even close to closing this discussion on Tuesday's hangout as topic came up last and that we would use next Tuesday for further conversation. Am I missing something?

cheers, 

Amelia Eiras 

twitter.com/ameliaeiras

Tribe: http://tomitribe.com      https://tribestream.io   

OSS:  http://microprofile.io     https://jakarta.ee

You received this message because you are subscribed to a topic in the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/G5WZvF0wZuY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to microprofile...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/775e8ac0-f40c-4939-a3e0-5784cadddaff%40googlegroups.com.

[John Clingan]

This is an ongoing conversation that I'd like to increase the activity on.

To unsubscribe from this group and all its topics, send an email to microprofile+unsubscribe@googlegroups.com.

[Ken Finnigan]

I think "Implementation First" is being used to refer to two different things in the charter.

One is that there must be an implementation that has updated to the latest specification RC and passed the TCK before the specification can be released as Final.

Second is the notion that MP specifications should come from proven ideas/implementations, as opposed to completely "blue sky" thinking without proven experience.

Do we need to disambiguate these two meanings?

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CAJ0g8j7gkMjLsPv%3D-N%2BRY7KbT7i2hh%2Bt32MM%2BK9GP0xCoG%3DQCA%40mail.gmail.com.

[Emily Jiang]

Emily, I agree with that characterizations for general vote makeup. Does this apply to annual(?) committer elections? All members vote on committer members, not just committer members vote on committer elections? This is my understanding, just wanna double-check.

I am not sure the election process for committer memebers. Are we allowed to establish MP way to elect committer members? If not, we could just adopt the Jakarta EE process for committer election.

Emily

[John Clingan]

FYI, Jakarta Committer Member terms and dates of election:

Elected representatives shall each serve one-year terms and shall be elected to serve from April 1 to March 31 of each calendar year, or until their respective successors are elected and qualified, or as otherwise provided for in this Charter. Procedures governing elections of Representatives may be established pursuant to resolutions of the Steering Committee provided that such resolutions are not inconsistent with any provision of this Charter.

Personally, I'm good with 1 year service term, although the start date may be different depending on when we finalize this.

Jakarta EE elections used the "Single Transferable Vote" process as identified in Section 3c of the Eclipse Bylaws, although I think 'sustaining member' would be 'corporate member' in the MicroProfile case:

"... means a voting process under which each Sustaining Member or Committer Member, as
applicable, shall be entitled to cast numbered preference votes for as many candidates as there
are open seats on the Board allocated to Sustaining Members and Committer Members, as
applicable. Votes that are not needed to elect a candidate and votes for candidates who do not
receive enough votes to be elected are transferred in accordance with the preferences of each
voter. "

Here is the wikipedia definition of Single Transferable Vote for general context.

[John Clingan]

While your broader point is understood, can you describe how you came to 4 members out of 6? I just want to make sure we are coming from a common understanding of the composition rules.

[Emily Jiang]

Thank you John! What you referred sounds reasonable.

Jakarta EE elections used the "Single Transferable Vote" process as identified in Section 3c of the Eclipse Bylaws, although I think 'sustaining member' would be 'corporate member' in the MicroProfile case:

"... means a voting process under which each Sustaining Member or Committer Member, as
applicable, shall be entitled to cast numbered preference votes for as many candidates as there
are open seats on the Board allocated to Sustaining Members and Committer Members, as
applicable. Votes that are not needed to elect a candidate and votes for candidates who do not
receive enough votes to be elected are transferred in accordance with the preferences of each
voter. "

Mike mentioned maximum 2 committer members from the same company as each corporate member. I think we need to nail down the corporate memeber first, which will define how many committer members are allowed.

Did you find out how the committer member is elected? I did a quick search earlier but did not find anything concrete.

Emily

[Paul Buck]

I think what Steve is getting at is if Red Hat and IBM are 2 of the 4 corporate members and the 2 committer reps are employees of either Red Hat or IBM then 4 of 6 are from the same corporate group. The composition of the committe is 4 corportae members + 2 committer reps based on the 2:1 model.

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/29d78421-5154-4911-b092-dd2a6b1627a8%40googlegroups.com.

[Mark Little]

Just getting back from vacation and catching up, so apologies in advance if this has already been covered.

Emily, you’re understanding of “implementation first” is not what we had in mind when we started MicroProfile. It was that no agreement on “standard” APIs for a particular problem space should be sought until there’s experience of what works in that domain and that experience comes from implementations. It most certainly was not that we should come together, define an API, go out and implement it and then come back and make tweaks to the API based upon that implementation (or those implementations). And the reason why? Because that latter approach is already well captured in open source culture and there’s no need for MicroProfile to be involved at all. We’ve been doing that for years … just look at the great cross-vendor/cross-community efforts elsewhere in the Eclipse Foundation, the ASF or elsewhere.

Mark.

 

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/c5377203-9127-4bc8-827b-99332973cfd5%40googlegroups.com.

[Mark Little]

Woa there! I know I’ve been on vacation for a week and not checking email but I’m kinda surprised no one else noticed this thread hijacking! Emily, probably an honest mistake on your part but the thread David created here was not about voting!

Mark.

[Emily Jiang]

David on 9th April focused this thread on the discussion of Experimentation and Implementation First, which was lifted from WG doc discussion. I just commented on David's email. IIUC, this thread is used for discussing the matters related to WG. Voting is one of issues.

Experimentation and Implementation First (Re: [microprofile] Working Group Standalone Proposal)

Having that said, it might make sense to life different topics and prefix with WG so that one conversation can happen per thread.

Apr 9

Thanks

Emily

[Emily Jiang]

Hi Mark,

We discussed this on the hangouts in the past two weeks. I am not the only person who hold the understanding I expressed of "implementation first" (release the spec after one implementation is available). I don't see why limiting the "implementation first" to some preexisting technologies. Obviously, if there are solutions available somewhere, sure, MicroProfile can borrow and build on top of them.

If no ready solution is available, MicroProfile is capable of observing problems, providing solutions, and test the solutions in the market. Are you saying MicroProfile is not the place to experiment (including no one has experimented it before) and fail fast? If the answer is no, this pretty much contradicts with the MP's experimentation spirit.

Emily

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/c5377203-9127-4bc8-827b-99332973cfd5%40googlegroups.com.

[Mark Little]

Hi Emily.

Can you please explain to me how “experimentation first” is different to doing this in a separate open source project (not part of MP) which is specifically set up to do an implementation? What you (and maybe others) are suggesting seems like a very complicated approach to getting experience about how to tackle a problem domain and then arrive at an agreed set of APIs, because remember that MP is not meant to be defining implementations but solely about defining a “standard” set of APIs which are derived from experience, which comes from implementation.

I’ll add something more inline ...

On 20 Apr 2020, at 10:35, 'Emily Jiang' via Eclipse MicroProfile <microp...@googlegroups.com> wrote:

Hi Mark,

We discussed this on the hangouts in the past two weeks. I am not the only person who hold the understanding I expressed of "implementation first" (release the spec after one implementation is available). I don't see why limiting the "implementation first" to some preexisting technologies.

Who said anything about limiting to pre-existing technologies (BTW I assume you mean implementations)? I would very much support people, vendors, groups etc going out and creating new open source projects to try out various alternative options and APIs to a problem even if there are existing implementations out there. Just because there are implementations doesn’t mean they have the right APIs.

What I am arguing against is doing these implementations under the MicroProfile project. Yes, those  implementations could be hosted at the Eclipse Foundation, but they could just as easily be hosted elsewhere. Whatever makes sense to grab community interest to try out what the implementers are trying to do. And only then would those results come back to the MicroProfile group to determine if it’s time to agree an API.

Correct me if I’m wrong, but you are suggesting those developers do an implementation (proof of concept) to agree on an API within the MicroProfile sandbox, take that proof of concept API and put it into an MP spec, and then iterate on the spec. once others implement it in their products? If that is the case then I see a number of problems but perhaps you can illuminate me on where I’m going wrong.

Obviously, if there are solutions available somewhere, sure, MicroProfile can borrow and build on top of them.

If no ready solution is available, MicroProfile is capable of observing problems, providing solutions,

MP was not set up to provide implementations (solutions) but APIs. Or are you suggesting APIs by themselves are solutions?

and test the solutions in the market. Are you saying MicroProfile is not the place to experiment (including no one has experimented it before) and fail fast? If the answer is no, this pretty much contradicts with the MP's experimentation spirit.

I believe you have a very different understanding of “experimentation” around MP than I do. First it’s “experience driven” that we spoke about when MP was originally create. We did/do talk about innovating outside of specification bodies and use JCP as an example of what we do not want to repeat. Your proposal sounds spookily close to the JCP approach. I’m not aware of where “experimentation” as a term was used around MP but I assume it was more around iterating over the APIs/specs based upon feedback from users of implementations which were then based upon the specs which were released by the MP community and not about experimenting on a PoC which fed into the APIs in the first place. In fact if we, as the MP community, have to define a PoC implementation in order to finalise or even just draft, an API set for a specification then I believe we have failed in our original aim to be experience driven.

Finally, please let me know how what you want to do cannot be accomplished by traditional open source efforts independently of MicroProfile?

Mark.

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/e62e1b96-3272-4345-856a-3e2debf159ea%40googlegroups.com.

---
Mark Little
mli...@redhat.com

JBoss, by Red Hat
Registered Address: Red Hat Ltd, 6700 Cork Airport Business Park, Kinsale Road, Co. Cork.
Registered in the Companies Registration Office, Parnell House, 14 Parnell Square, Dublin 1, Ireland, No.304873
Directors:Michael Cunningham (USA), Vicky Wiseman (USA), Michael O'Neill, Keith Phelan, Matt Parson (USA)

[Mark Little]

I checked David’s original email which created this thread and it doesn’t use the word ‘vote’ in it at all. He did create a separate thread about voting and that’s where those topics should be discussed, not here.

Mark.

On 20 Apr 2020, at 10:10, 'Emily Jiang' via Eclipse MicroProfile <microp...@googlegroups.com> wrote:

David on 9th April focused this thread on the discussion of Experimentation and Implementation First, which was lifted from WG doc discussion. I just commented on David's email. IIUC, this thread is used for discussing the matters related to WG. Voting is one of issues.

Experimentation and Implementation First (Re: [microprofile] Working Group Standalone Proposal)

Having that said, it might make sense to life different topics and prefix with WG so that one conversation can happen per thread.

Apr 9

Thanks

Emily

On Monday, April 20, 2020 at 9:35:04 AM UTC+1, Mark Little wrote:

Woa there! I know I’ve been on vacation for a week and not checking email but I’m kinda surprised no one else noticed this thread hijacking! Emily, probably an honest mistake on your part but the thread David created here was not about voting!

Mark.

On 14 Apr 2020, at 23:12, 'Emily Jiang' via Eclipse MicroProfile <microp...@googlegroups.com> wrote:

Back to David's question:

What if a specification vote was considered passed if it passes both a super-majority of corporate members and a super-majority of committers members?

My understanding is that corporate member and committer memebers are mashed together, no distinction. The super marjority applies to the total of corporate and committer members. 

e.g. 

A WG:  10 corporate members and 5 committer members (2:1 ratio)

For a specification vote to pass: 10 (2/3 of voters) votes and 8 (over half voters) postive votes

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/b985ab8d-cea7-4cfd-aee9-73fe3d25dcd7%40googlegroups.com.
<Auto Generated Inline Image 1.png>

[Emily Jiang]

I checked David’s original email which created this thread and it doesn’t use the word ‘vote’ in it at all. He did create a separate thread about voting and that’s where those topics should be discussed, not here.

 Mark, ah, I realised what you meant now. I replied on this mailinglist conversation from google group instead of my gmail inbox directly so I commented on both topics in one reply. My apoliges for messing up the thread abstracts!

Emily

On Monday, April 20, 2020 at 11:57:02 AM UTC+1, Mark Little wrote:

I checked David’s original email which created this thread and it doesn’t use the word ‘vote’ in it at all. He did create a separate thread about voting and that’s where those topics should be discussed, not here.

Mark.

On 20 Apr 2020, at 10:10, 'Emily Jiang' via Eclipse MicroProfile <microp...@googlegroups.com> wrote:

David on 9th April focused this thread on the discussion of Experimentation and Implementation First, which was lifted from WG doc discussion. I just commented on David's email. IIUC, this thread is used for discussing the matters related to WG. Voting is one of issues.

Experimentation and Implementation First (Re: [microprofile] Working Group Standalone Proposal)

Having that said, it might make sense to life different topics and prefix with WG so that one conversation can happen per thread.

<Auto Generated Inline Image 1.png> Apr 9

Thanks

Emily

On Monday, April 20, 2020 at 9:35:04 AM UTC+1, Mark Little wrote:

Woa there! I know I’ve been on vacation for a week and not checking email but I’m kinda surprised no one else noticed this thread hijacking! Emily, probably an honest mistake on your part but the thread David created here was not about voting!

Mark.

On 14 Apr 2020, at 23:12, 'Emily Jiang' via Eclipse MicroProfile <microp...@googlegroups.com> wrote:

Back to David's question:

What if a specification vote was considered passed if it passes both a super-majority of corporate members and a super-majority of committers members?

My understanding is that corporate member and committer memebers are mashed together, no distinction. The super marjority applies to the total of corporate and committer members. 

e.g. 

A WG:  10 corporate members and 5 committer members (2:1 ratio)

For a specification vote to pass: 10 (2/3 of voters) votes and 8 (over half voters) postive votes

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.

To unsubscribe from this group and stop receiving emails from it, send an email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/b985ab8d-cea7-4cfd-aee9-73fe3d25dcd7%40googlegroups.com.
<Auto Generated Inline Image 1.png>

[John Clingan]

The election "process" I am not sure about. Here is where I think we are:

1. The results are public
2. Whether who votes for whom is public is TBD. That's up to us.
3. The duration of the voting process is TBD, but I'm assuming one week.

We need to finish off the composition vote as well.

[Emily Jiang]

Hi Mark,

After reading all of your comments, I believe you have misunderstood what I meant by saying implemantation first. "Implemenation First" means at least one implemenation has passed all MP TCKs and then the corresponding MP specs can be released. I did not suggest to ask MP to offer implementations. I did not make any new proposal, as we have been using this rule for our releases in order to guarantee our TCKs are correct.

In summary, MP only contains API, TCK, and Spec. The implementations are somewhere else, such as Open Liberty, SmallRye, Payara, TomEE, etc.

I think you also agreed that in MP, we can define our own API, behaviours, etc not limited by the existing implemenations. Again I agree with you.

more clarificaton inline.

Thanks

Emily

On Monday, April 20, 2020 at 11:55:08 AM UTC+1, Mark Little wrote:

Hi Emily.

Can you please explain to me how “experimentation first” is different to doing this in a separate open source project (not part of MP) which is specifically set up to do an implementation? What you (and maybe others) are suggesting seems like a very complicated approach to getting experience about how to tackle a problem domain and then arrive at an agreed set of APIs, because remember that MP is not meant to be defining implementations but solely about defining a “standard” set of APIs which are derived from experience, which comes from implementation.

 

My summary note should explain the misunderstanding.

I’ll add something more inline ...

On 20 Apr 2020, at 10:35, 'Emily Jiang' via Eclipse MicroProfile <microp...@googlegroups.com> wrote:

Hi Mark,

We discussed this on the hangouts in the past two weeks. I am not the only person who hold the understanding I expressed of "implementation first" (release the spec after one implementation is available). I don't see why limiting the "implementation first" to some preexisting technologies.

Who said anything about limiting to pre-existing technologies (BTW I assume you mean implementations)? I would very much support people, vendors, groups etc going out and creating new open source projects to try out various alternative options and APIs to a problem even if there are existing implementations out there. Just because there are implementations doesn’t mean they have the right APIs.

What I am arguing against is doing these implementations under the MicroProfile project. Yes, those  implementations could be hosted at the Eclipse Foundation, but they could just as easily be hosted elsewhere. Whatever makes sense to grab community interest to try out what the implementers are trying to do. And only then would those results come back to the MicroProfile group to determine if it’s time to agree an API.

Correct me if I’m wrong, but you are suggesting those developers do an implementation (proof of concept) to agree on an API within the MicroProfile sandbox, take that proof of concept API and put it into an MP spec, and then iterate on the spec. once others implement it in their products? If that is the case then I see a number of problems but perhaps you can illuminate me on where I’m going wrong.

Mark, we are in agreement here. I did not mean making MP to contain implementations. The implementation means implementations somewhere such as Open Liberty, SmallRye, Payara, somewhere else. In summary, MP only contains API, Specs, and TCKs.

Obviously, if there are solutions available somewhere, sure, MicroProfile can borrow and build on top of them.

If no ready solution is available, MicroProfile is capable of observing problems, providing solutions,

MP was not set up to provide implementations (solutions) but APIs. Or are you suggesting APIs by themselves are solutions?

I meant MP specs define the behaviours, which will fix some real use cases.

and test the solutions in the market. Are you saying MicroProfile is not the place to experiment (including no one has experimented it before) and fail fast? If the answer is no, this pretty much contradicts with the MP's experimentation spirit.

I believe you have a very different understanding of “experimentation” around MP than I do. First it’s “experience driven” that we spoke about when MP was originally create. We did/do talk about innovating outside of specification bodies and use JCP as an example of what we do not want to repeat. Your proposal sounds spookily close to the JCP approach. I’m not aware of where “experimentation” as a term was used around MP but I assume it was more around iterating over the APIs/specs based upon feedback from users of implementations which were then based upon the specs which were released by the MP community and not about experimenting on a PoC which fed into the APIs in the first place. In fact if we, as the MP community, have to define a PoC implementation in order to finalise or even just draft, an API set for a specification then I believe we have failed in our original aim to be experience driven.

Finally, please let me know how what you want to do cannot be accomplished by traditional open source efforts independently of MicroProfile?

I like what you said "In fact if we, as the MP community, have to define a PoC implementation in order to finalise or even just draft, an API set for a specification then I believe we have failed in our original aim to be experience driven.". Experimentation around MP is purely a word to state what we are doing in MP is iterative and fix ourselves if we have made any mistakes.

Mark.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/e62e1b96-3272-4345-856a-3e2debf159ea%40googlegroups.com.

[Mark Little]

Hi Emily.

I didn’t misunderstand, it’s just a different meaning. Let me break it down for you:

- in your definition of “implementation first” there appears to be no need for pre-existing experience based implementations elsewhere in our world to exist for MP people to come together and craft a set of APIs, i.e., they could do that work in a vacuum of experience. Then the APIs are created, someone(s) creates an implementation to try out the APIs and the MP community decides it’s a good thing and ratifies the APIs.

- in my definition of “implementation first” there must be pre-existing implementations in our world, no matter the implementation language or platform, that are trying to solve the problem at hand. Ideally there’s more than one implementation and even better, a different set of opinions on APIs therein. The MP community comes together, hopefully with some or all of these implementation developers, and comes up with a set of Java APIs which these implementations then try to adhere to, or new implementations come out based on these APIs. Eventually the MP community decides it’s a good thing and ratifies the APIs.

See the difference?

Mark.

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/5785bdf2-699a-4201-b615-f4ede2cc5f7b%40googlegroups.com.

[Emily Jiang]

Hi Mark,

Thanks for the clarification! This is what I understood before about our different opinions, but I was confused yesterday morning. I am clear now. As for your understanding below, I have a couple of questions.

- in my definition of “implementation first” there must be pre-existing implementations in our world, no matter the implementation language or platform, that are trying to solve the problem at hand. Ideally there’s more than one implementation and even better, a different set of opinions on APIs therein. The MP community comes together, hopefully with some or all of these implementation developers, and comes up with a set of Java APIs which these implementations then try to adhere to, or new implementations come out based on these APIs. Eventually the MP community decides it’s a good thing and ratifies the APIs.

 

Questions:

1. I assume the APIs, behaviours defined in MP should not be limited by the existing implementations. MP should be flexible to choose a different way to trackle the problem. The existing implementations should be just served as an inspiration but not force MP to adopt the same behaviour and API. I think you hinted in the past reponses, but I would like to double check.

2. As for the assertion on the pre-exising implementation, at what details you are asking for? As for MP JWT, we are seeking to how to secure microservices and interoperable, I am not sure to whether this issue was solved by any existing open source projects. I don't understand why we limit us to preexisting implmentations. In the fast moving world, new issues arises and hurt us. Why don't we do something rather than waiting for others to make the solution first? If we couldn't, it is a different matter.

My 2cents.

Emily

You received this message because you are subscribed to a topic in the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/G5WZvF0wZuY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to microprofile...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/699BAAF6-9B78-4958-9D55-93AB97819B24%40redhat.com.

--

Thanks
Emily

[m.reza.rahman]

I really wonder if this is splitting hairs and not a distinction worth worrying about. I doubt anyone would want to aim to standardize something where there isn't prior art one can point to of some kind or the other.

I would personally stay away from implying the prior art needs to be in the form of an implementation that very directly manifests the idea in the process of being standardized. I think that kind of approach is probably only the domain of formal standards bodies and something like MicroProfile should allow for more flexibility especially if the focus is more lightweight standadization that errs more on the side of innovation to meet rapidly evolving market needs.

Reza Rahman

Jakarta EE Ambassador, Author, Blogger, Speaker

Please note views expressed here are my own as an individual community member and do not reflect the views of my employer.

Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone

-------- Original message --------

From: 'Emily Jiang' via Eclipse MicroProfile <microp...@googlegroups.com>

Date: 4/21/20 11:43 AM (GMT-05:00)

To: MicroProfile <microp...@googlegroups.com>

Subject: Re: Experimentation and Implementation First (Re: [microprofile] Working Group Standalone Proposal)

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CAECq3A9dPM-nDF53uXL5eZsvrdp2Z1eh5bdxEao1HJASwTR0Ew%40mail.gmail.com.

[David Lloyd]

It's not splitting hairs IMO; this is currently causing actual
problems in the MP Config specification, so these questions need
definitive answers.

> To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/5e9f32d2.1c69fb81.3dee1.e9d1%40mx.google.com.



--
- DML

[Emmanuel Bernard]

I don’t see this as splitting hair. I don’t think having prior art experience is a given or taken at the level it should in all situations. It is a difficult balance as MP does aim at a rapidly evolving requirement set. 

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/5e9f32d2.1c69fb81.3dee1.e9d1%40mx.google.com.

[Mark Little]

Hi Emily.

Inline ...

On 21 Apr 2020, at 16:43, 'Emily Jiang' via Eclipse MicroProfile <microp...@googlegroups.com> wrote:

Hi Mark,

Thanks for the clarification! This is what I understood before about our different opinions, but I was confused yesterday morning. I am clear now. As for your understanding below, I have a couple of questions.

- in my definition of “implementation first” there must be pre-existing implementations in our world, no matter the implementation language or platform, that are trying to solve the problem at hand. Ideally there’s more than one implementation and even better, a different set of opinions on APIs therein. The MP community comes together, hopefully with some or all of these implementation developers, and comes up with a set of Java APIs which these implementations then try to adhere to, or new implementations come out based on these APIs. Eventually the MP community decides it’s a good thing and ratifies the APIs.

 

Questions:

1. I assume the APIs, behaviours defined in MP should not be limited by the existing implementations.

No, definitely not. What goes in (experience and solid examples of APIs which work) need not look like what comes out. However, what comes out should be based upon the experience and understanding of what went in :)

MP should be flexible to choose a different way to trackle the problem. The existing implementations should be just served as an inspiration but not force MP to adopt the same behaviour and API. I think you hinted in the past reponses, but I would like to double check.

Yes but only to a point. Let me give you an example from my favour distributed computing domain, transactions. And specifically the relationship between XA (the X/Open standard) and JTA. The former existed for almost 2 decades before JTA came on the scene and was very successfully employed into various relational databases and other standards (e.g., the OMGs OTS). Now suppose JTA didn’t exist and MP wanted to create a standard transactional API based upon the success of XA. The input is clearly XA and TX for resource and transaction demarcation respectively. XA defines transactional properties using 2PC as the consensus algorithm, as we all know.

Now what I’d expect from the MP community would be something which defined an API that was influenced by XA and TX but could definitely deviate from it where it made sense for MP and where it wouldn’t invalidate all of the existing XA users out there. Sure, if it’s relatively easy/straightforward to put a shim/veneer over existing efforts and there’s a clear benefit to do that, then fair enough. But if the MP output was such that it required completely new implementations to this problem then I think we’ve failed. One example of this might be where someone in  the MP effort decides that whilst 2PC is great, 3PC is better so MP makes that a mandatory part of the result. That’d be a fail.

2. As for the assertion on the pre-exising implementation, at what details you are asking for? As for MP JWT, we are seeking to how to secure microservices and interoperable, I am not sure to whether this issue was solved by any existing open source projects. I don't understand why we limit us to preexisting implmentations. In the fast moving world, new issues arises and hurt us. Why don't we do something rather than waiting for others to make the solution first? If we couldn't, it is a different matter.

If there’s a problem area and no existing solution/implementation then I would prefer people get together and create a new open source project for that and run it for a year or so to get feedback and real world use cases. In that case those people are groundbreakers and would then provide the pre-existing implementation when it comes back to MP and by then hopefully more than one exists.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CAECq3A9dPM-nDF53uXL5eZsvrdp2Z1eh5bdxEao1HJASwTR0Ew%40mail.gmail.com.

[m.reza.rahman]

To be honest, like Emily I am a bit confused then why such a lengthy discussion on this is really necessary. However, maybe we can clarify this quickly. How would one view things like Servlet, JTA, JMS, JAX-WS, JSF, JAX-RS, @Schedule, @Asynchronous and so many pretty sucessful things that came out of the JCP? In all of these cases, there was some prior art, but nothing like the relationship between JPA and Hibernate for example. In the latter case, the Hibernate team directly contributed to JPA and JPA later implemented Hibernate. For the former cases, there were no possible candidate implementations when the specification work started.

If we don't really see any real distinction between these cases, I am afraid this does feel a bit like needlessly quibbling on semantics to me. Perhaps a more pragmatic path is not having guidelines that feel a bit too rigid and simply evaluate on a case by case basis what idea is worth pursuing in MicroProfile and what is not? Isn't this the kind of gray decisions you need a governance body for that hopefully will have the best interests of everyone in mind like the probability that an individual specification or feature will succeed?

Reza Rahman

Jakarta EE Ambassador, Author, Blogger, Speaker

Please note views expressed here are my own as an individual community member and do not reflect the views of my employer.

Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone

-------- Original message --------

From: Emmanuel Bernard <eber...@redhat.com>

Date: 4/22/20 2:01 AM (GMT-05:00)

To: microp...@googlegroups.com

Subject: Re: Experimentation and Implementation First (Re: [microprofile] Working Group Standalone Proposal)

I don’t see this as splitting hair. I don’t think having prior art experience is a given or taken at the level it should in all situations. It is a difficult balance as MP does aim at a rapidly evolving requirement set. 

On Tue 21 Apr 2020 at 19:52, m.reza.rahman <m.reza...@gmail.com> wrote:

I really wonder if this is splitting hairs and not a distinction worth worrying about. I doubt anyone would want to aim to standardize something where there isn't prior art one can point to of some kind or the other.

I would personally stay away from implying the prior art needs to be in the form of an implementation that very directly manifests the idea in the process of being standardized. I think that kind of approach is probably only the domain of formal standards bodies and something like MicroProfile should allow for more flexibility especially if the focus is more lightweight standadization that errs more on the side of innovation to meet rapidly evolving market needs.

Reza Rahman

Jakarta EE Ambassador, Author, Blogger, Speaker

Please note views expressed here are my own as an individual community member and do not reflect the views of my employer.

Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone

-------- Original message --------

From: 'Emily Jiang' via Eclipse MicroProfile <microp...@googlegroups.com>

Date: 4/21/20 11:43 AM (GMT-05:00)

To: MicroProfile <microp...@googlegroups.com>

Subject: Re: Experimentation and Implementation First (Re: [microprofile] Working Group Standalone Proposal)

Hi Mark,

Thanks for the clarification! This is what I understood before about our different opinions, but I was confused yesterday morning. I am clear now. As for your understanding below, I have a couple of questions.

- in my definition of “implementation first” there must be pre-existing implementations in our world, no matter the implementation language or platform, that are trying to solve the problem at hand. Ideally there’s more than one implementation and even better, a different set of opinions on APIs therein. The MP community comes together, hopefully with some or all of these implementation developers, and comes up with a set of Java APIs which these implementations then try to adhere to, or new implementations come out based on these APIs. Eventually the MP community decides it’s a good thing and ratifies the APIs.

 

Questions:

1. I assume the APIs, behaviours defined in MP should not be limited by the existing implementations. MP should be flexible to choose a different way to trackle the problem. The existing implementations should be just served as an inspiration but not force MP to adopt the same behaviour and API. I think you hinted in the past reponses, but I would like to double check.

2. As for the assertion on the pre-exising implementation, at what details you are asking for? As for MP JWT, we are seeking to how to secure microservices and interoperable, I am not sure to whether this issue was solved by any existing open source projects. I don't understand why we limit us to preexisting implmentations. In the fast moving world, new issues arises and hurt us. Why don't we do something rather than waiting for others to make the solution first? If we couldn't, it is a different matter.

My 2cents.

Emily

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/5e9f32d2.1c69fb81.3dee1.e9d1%40mx.google.com.

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CANYWk7P%3DbK6rm2YcYqzpuTAXF2tRm5e9XVS%3DdaOsNuL0zJffbg%40mail.gmail.com.

[Ondro Mihályi]

I think we're discussing this too much already with any resolution. What Reza suggested makes like a good compromise to me and is in line with the spirit and goals of MicroProfile.

We should primarily evaluate all ideas thoroughly before reaching agreement on them. Something might seem iseful and clear one day but can become blurry the next day after some thought.

If there are some existing implementations and experience, we should take it into account. And we should actively search for existing solutions and experience to avoid reinventing the wheel. A good example is MP Config where we compared at least 3 existing config frameworks and even got involved some of their authors in the spec.

If there are no implementations, we should investigate best practices and patterns and then slowly specify each aspect piece by piece after careful evaluation. A good example is MP Fault Tolerance which tried to cover multiple widely known patterns one by one. MP JWT was similar as it based on the JWT standard and documented security pattern but it was initially a one man show and suffered from the lack of evaluation by peers.

If there's something completely new, we still can evaluate ideas to support it but this should be approached woth caution and standardized only if there's wide consensus. A good example is the Service Mesh initiative which evaluated support for service meshes for a long time and then didn't even materialize into a separate spec because it made more sense to amend existing specs.

I always value discussion, careful evaluation and desire to find the best solution backed by argument, experience and research. I applied this recently in MP config discussions not because I was against some idea but because I didn’t want to jump to an idea that looks tempting but may shoot us in the foot later. And I believe discussions like we have in MP Config are very important though they must result in some productive work in the end to be useful.

Ondro

[Amelia Eiras]

This week's WG discussion potential converts draft v_0.2 of the Stand Alone Chapter to v_ 0.3 for the next step/focus- BUDGET.

NOW, Tracing our steps as a few relevant  items (branding requirements) need to be worked out in parallel with the completion of the Chapter. 
Brings us to the pay closer attention to the MP Mktg MicroProfilers and the future Mktg hangouts. 

MP-Mktg Hangout agenda minutes HERE follows the same format as the Community hangouts, twice per month, 1 day before the Community hangout. The next call is next Monday, May 11th, 10-11am PDT- zoom access HERE:  https://eclipse.zoom.us/j/4616298762. MP Calendar for those who might want to import it. 

Anyone is welcomed to:

•  show up, 
• listen, 
• ask questions 
• help. :) 
• Any task (THE NORM FOR THIS PROJECT) will follow MP branding efforts/processes such as the use Mktg REPO git issues, welcome Community feedback early on, -- no deviations from how this project has accomplished any of its past branding is expected. :)  
  

With this message, my hope is to set expectations that YOU, interested MicroProfiler,  want to collaborate from day zero of those conversations, you are MOST WELCOMED, branding/marketing experience not required--  perspectives are valuable, diverse ways of thinking are valuable. 

Cheers,  

[Werner Keil]

Sometimes things are proposed before their time. We saw that on several occasions when we started working on Units of Measurements around 2005 and even 5 years later the idea was considered just for a few math geeks, and the JCP EC turned it down (while the community continued to use it nevertheless) Then came IoT and the rest is history.

Antoine and I proposed a Social Spec to the JCP a few years ago which never materialized as a whole mostly because like the whole OpenTracing vs. OpenTelemetry vs. whatever else might come dilemma was very similar then and standardizing these various connectors to social APIs beyond the fact most of them use REST wasn't seen doable. 

What did get standardized however is the security aspect with Oauth etc. in Jakarta Security and some other aspects like MP JWT are also dealt with here.

Maybe there should be a Sandbox or Incubator, but several Eclipse projects have that, e.g. Mylyn with an idea for an SQL connector https://wiki.eclipse.org/index.php?title=Mylyn/Incubator/Generic_Industrial_Connector, not sure, if it ever got anywhere, but it's a good example for an experimental space in an otherwise mature TLP.

And beside the WG it is hard to imagine that MP can work in the future without a TLP along the lines of EE4J https://projects.eclipse.org/projects/ee4j or Mylyn: https://projects.eclipse.org/projects/mylyn which also includes the incubator.

A combined Steering/Spec committee might make sense, would that have 2, 4 or more elected committer members? 

Telling from the current Jakarta EE committee elections, there is no strict rule written down, that a committer should not be employed by a corporate member that is also a member of the same committee, how about that for MP? Would that allow Ondro or Sebastian to be a committer candidate or should it be only those who also run in the Jakarta EE elections right now and are not affiliated with member companies like Arjan or Otavio?

Telling from the lack of interest and candidates a Marketing committee may have similar problems here, so unless a combined committee for spec/steering had an influence on the committer members I see it very hard to fill 5, 4 or even just 2 marketing seats with committer members, even if you allowed employees of corporate members, but what kind of diversity or value would they have because each company normally has a corporate marketing policy and there's not much they could provide compared to their official company reps.

Werner 

[Amelia Eiras]

Lindo (beautiful) Miércoles to every MicroProfiler, 

Yesterday during the Community hangout a new update to the Working Charter occurred. The informal Budget draft was added as Schedule A - Working Group Fees and IS NOW ready for this Community review & further questions & consideration. 

This AM, I added via "suggestive mode" 2 items to the Charter. Our conversations during the call yesterday was influential to this AM's written feedback. :) 

https://docs.google.com/document/d/1cCMN298rUAX45Nq-ZJv755WZe8yVjyAo1Gz_wN8r7wc/edit#heading=h.7f0n2u91lr3h

• Page 2: Membership: Earn Authority- protecting how Committer status gets earned in this Community. Not by "pay to play" upon joining as a Corporate member but by public contributions, 4years done & protected moving forward under the WG.
• Page 7: Distribution of Annual Fees. Focusing on Schedule A, it is the job of this document to explain the core basics of how MP operates at the main level. I firmly belief that money becomes a burden when left unchecked. MicroProfile needs to support a paying ecosystem that protects not only what currently is but also that puts in writing who we are and what we stand form as a community. Money talks are easy if we are upfront with how we plan to use any budget. Any "coyness" about how budget could be spent, etc needs to be replace by write up that pictures where we want to go.

Though, we thought we might need next week's Working Group call, now after working on the Charter I believe that the call ought to happen to enable more conversation to hash up the new additions to the Charter. 

It is my hope that this message triggers at least 1 MicroProfiler not currently an editor to the Charter to suggest, comment- etc. Questions are most valuable at this time. :) AskMeAnything, AMA is the model in this ecosystem.

Cheers with tea, 

A. 

[Amelia Eiras]

Important WG Charter UPDATES after today's 1hr dedicated MP Working Group zoom call:

1) Charter draft is final: It has taken us about 3 months & 1/2 to diligently collaborate on the writing the MicroProfile Working Group Charter, today completed making it version final or v.-5: https://docs.google.com/document/d/1cCMN298rUAX45Nq-ZJv755WZe8yVjyAo1Gz_wN8r7wc/edit#

The document' status no longer welcomes comments as it will be sent to the EF Team for final approval before it goes into the EF Working Group space and the MP website. 

2) Once approval is granted, the MPWG will start its work on writing the Working Group Agreement. We don't expect to start from zero as MP is not the first Eclipse WG project, yet this will required legal budget to be taken from 2020 fees. 

3)  MicroProfile name is simplified under the Working Group as 1 word dropping the Eclipse from its name. 

The git ticket and new ones will trace compliance to standardize implication across everything that is MP: [MPWG adjustments] With the WG, the name changes to MicroProfile #289

4) There are some questions being asked to the Eclipse Foundation about the logic of the current Solutions Membership tier fees. This is a work in process, after today made public so that tracing & resolution comes to this thread and forum as part of the Charter & discussions. 

 Please check today's agenda call for exact details but main issue is: 

1. Why would a not-for-profit organization be required to pay $5k when a Corporation for-profit under 1million revenue be required to pay $1.500 USD? yearly under the Solutions Membership

5) The ACGNJ JUG community announced during today's hangout its interest on becoming a formal MPWG member as have also indicated the Atlanta & Chicago JUGs!   :)

-end of update from today's wonderful and productive call. A!