--
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.
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.
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/D19AEF07-E215-4399-A714-A490F2C5CF3C%40tomitribe.com.
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/D19AEF07-E215-4399-A714-A490F2C5CF3C%40tomitribe.com.
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.
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.
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.
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?
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/c5377203-9127-4bc8-827b-99332973cfd5%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/6074E7E1-97ED-49B9-98B7-F3B8D4F40C18%40tomitribe.com.
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.
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.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile+unsubscribe@googlegroups.com.
... 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.
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.
To unsubscribe from this group and all its topics, send an email to microprofile+unsubscribe@googlegroups.com.
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, 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.
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.
"... 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. "
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. "
--
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.
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.
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 |
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/c5377203-9127-4bc8-827b-99332973cfd5%40googlegroups.com.
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.
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.
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.
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
ThanksEmily
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>
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.
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 9ThanksEmily
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>
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 view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/e62e1b96-3272-4345-856a-3e2debf159ea%40googlegroups.com.
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.
- 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.
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/5e9f32d2.1c69fb81.3dee1.e9d1%40mx.google.com.
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.
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CAECq3A9dPM-nDF53uXL5eZsvrdp2Z1eh5bdxEao1HJASwTR0Ew%40mail.gmail.com.
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 RahmanJakarta EE Ambassador, Author, Blogger, SpeakerPlease 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.
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