MicroProfile Working Group discussion - Push vs pull

[John Clingan]

First, I am a day late on this, so sorry. Been traveling and I wanted to take more detailed notes which required re-listening to the recording again (takes longer than it looks!). I wanted to give a bit of context via notes on what led to this "pull" approach, which are possibly too detailed. Recording is here as well for others that want to listen and perhaps make modifications / updates to notes. Also, feel free to make updates/corrections to my description of the conclusion.

The conclusion of the call, not necessarily with 100% agreement but with some consensus, is to propose the idea of a specification "pull" model. What does this mean?

1. MicroProfile continues to deliver specs they way it delivers specs today in order to maintain speed and agility over long-term stability. The implication is incremental updates in February and October, major updates (which may include breaking changes) in June if there is a reason to have a major update. While we have delivered this way for 2-3 years, this is not a 100% rule. It may occasionally (hopefully rarely) get broken. For example, we may have to do more than one major update this year to integrate the Jakarta namespace.
2. MicroProfile makes no assumptions about how communities adopt MicroProfile specs, nor plans to make alignment agreements with those communities. 
3. Any community that consumes MicroProfile specifications can decide how it intends to consume ("pull") them. It can change namespaces, fork the spec and "go its own way", pick a version to use and occasionally re-sync with a MicroProfile version, etc. Any of these approaches is acceptable to the MicroProfile community. 
4. Any discussion regarding how specifications are consumed and the impact of that consumption should be done outside the MicroProfile community. For example, how can an implementation be both Jakarta EE and MicroProfile compatible if there is a namespace change? If a community changes namespaces or changes API definition, for example, how does this impact the IP grant flow? These are discussions for the those communities. Many of us also participate in the Jakarta  community and can have these conversations there.

The intent is to finish up the discussion and decide on it at the next live hangout (Feb 18th, if possible). Some of us will be traveling to DevNexus next week and this may impact attendance. So, let's have as much of this conversation here before the Hangout.

Thanks!

[Steve Millidge]

Hi John,

You write "decide on it at the next live hangout ". How is the decision being made? Is there a vote? Who gets to vote?

Given this is a far reaching policy statement shouldn't this go to an asynch vote rather than a synch vote at a hangout?

Steve

[Rudy De Busscher]

Hi John,

Thank you for the summary.

Regarding when and how we should make a decision, shouldn't we hold a voting as any other OpenSource projects does? Every committer can reply with -1/0/1 for at least 72h hours. And since also the Hangout is open to everyone, maybe we should also be open to the users of MicroProfile who have an idea of how they would like to use it in the future.

Otherwise, we may miss some important feedback from the community.

Regards

Rudy

[m.reza.rahman]

To be honest, some of the decision making patterns really bother me and I also would like some clarity. It seems like a whole lot of decisions are made in these Hangouts. None of these decisions seem to ever be documented or summarized in some kind of more open forum to be discussed further with people that can't be present (which probably is the majority of the committers let alone the end user types like me).

I tried to listen to a few of the recordings of these Hangouts in the very early days. I quickly gave up. It felt more like a social gathering for a small clique rather than a business meeting. What I actually got out of it I could have gotten in five minutes skimming an email. How is this worth it for anyone who isn't getting paid to attend these even if they could somehow make the schedule and time commitment work?

How does this actually work and how does it align with any sense of openness or inclusion? Again, does the Eclipse Foundation have any guidelines or best practices on what should and shouldn't be done? Is any of this actually meeting those best practices?

What am I missing here? Some enlightenment would be highly appreciated.

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: Steve Millidge <l33t...@gmail.com>

Date: 2/14/20 1:46 PM (GMT+00:00)

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

Subject: [microprofile] Re: MicroProfile Working Group discussion - Push vs pull

Hi John,

You write "decide on it at the next live hangout ". How is the decision being made? Is there a vote? Who gets to vote?

Given this is a far reaching policy statement shouldn't this go to an asynch vote rather than a synch vote at a hangout?

Steve

On Thursday, 13 February 2020 22:58:16 UTC, John Clingan wrote:

First, I am a day late on this, so sorry. Been traveling and I wanted to take more detailed notes which required re-listening to the recording again (takes longer than it looks!). I wanted to give a bit of context via notes on what led to this "pull" approach, which are possibly too detailed. Recording is here as well for others that want to listen and perhaps make modifications / updates to notes. Also, feel free to make updates/corrections to my description of the conclusion.

The conclusion of the call, not necessarily with 100% agreement but with some consensus, is to propose the idea of a specification "pull" model. What does this mean?

1. MicroProfile continues to deliver specs they way it delivers specs today in order to maintain speed and agility over long-term stability. The implication is incremental updates in February and October, major updates (which may include breaking changes) in June if there is a reason to have a major update. While we have delivered this way for 2-3 years, this is not a 100% rule. It may occasionally (hopefully rarely) get broken. For example, we may have to do more than one major update this year to integrate the Jakarta namespace.
2. MicroProfile makes no assumptions about how communities adopt MicroProfile specs, nor plans to make alignment agreements with those communities. 
3. Any community that consumes MicroProfile specifications can decide how it intends to consume ("pull") them. It can change namespaces, fork the spec and "go its own way", pick a version to use and occasionally re-sync with a MicroProfile version, etc. Any of these approaches is acceptable to the MicroProfile community. 
4. Any discussion regarding how specifications are consumed and the impact of that consumption should be done outside the MicroProfile community. For example, how can an implementation be both Jakarta EE and MicroProfile compatible if there is a namespace change? If a community changes namespaces or changes API definition, for example, how does this impact the IP grant flow? These are discussions for the those communities. Many of us also participate in the Jakarta  community and can have these conversations there.

The intent is to finish up the discussion and decide on it at the next live hangout (Feb 18th, if possible). Some of us will be traveling to DevNexus next week and this may impact attendance. So, let's have as much of this conversation here before the Hangout.

Thanks!

--
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/66f8b70a-f144-4893-b530-ddb4944018e0%40googlegroups.com.

[John Clingan]

There are two voting mechanisms within MicroProfile:

1) Consensus. We have always made decisions on the live hangout up until this point. It's basically our version of the steering committee meeting, but with a community/collaborative approach. MicroProfile markets the Live Hangout in general and these working group discussions frequently. We label "DECISION'  in bold in the meeting minutes on key decisions made. This approach has been a contributing factor for the velocity that MicroProfile has been able to achieve. 

2) Committers. The eclipse process for voting on committers is well established, and we've been using the EDP for voting no committers.

To date we have been able to make decisions based on consensus. However, there will be times when this is not an ideal approach - like when consensus cannot be achieved. I am completely open to applying 2) to voting on far-reaching decisions like this. I am simply following the first approach we have used for 3+ years - consensus - before switching to #2. BTW, we posted this thread because we wanted more discussion and feedback.

Reza, you may not prefer the approach of the live hangout, but's it's been how we've been operating for years. This is one of the reasons I refer to MicroProfile as an open source community that creates specifications and not as a standards organization. You are tapping into one of the very reasons why, IMHO, MicroProfile should remain in a standalone working group. It's a very unique approach with its own culture.

Hope this helps.

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

[John Clingan]

Important edit: "voting no committers" should be "voting on committers" :-)

[Rudy De Busscher]

And in the case the consensus scenario doesn't work as we have now with the technical alignment and the WG discussion? Is consensus than the same as majority? How will that be determined?

Formal public voting will be the easiest, transparent and open-source project worthy solution.

Rudy

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

[Dmitry Kornilov]

IMO, consensus between 14 people present on the last Hangout doesn’t reflect a consensus in the MicroProfile community. I see many voices against separate WG. I didn’t count, but it easily can be more than 50% of all who posted. 

You need do a public voting and invite not only committers but also consumers.

-- Dmitry

сб, 15 февр. 2020 г. в 19:56, Rudy De Busscher <rdebu...@gmail.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/542925cb-7e07-4fbe-acaa-5402f450c8b2%40googlegroups.com.

[John Clingan]

Dmitry, the Hangout has been where we discuss issues and try to come to a consensus, sometimes with the aid of the google group in between hangouts. It's been that way since day one. There isn't a formal definition of consensus. Consensus has meant that everyone who participates in the Hangouts agrees to move forward. FYI, a bulk of those who participate in the hangouts, historically, have been spec authors, some marketing folks, committers, and contributors. We sometimes get community members, and we encourage them to participate.

Consensus has worked to date, but may not work here. If we can't reach consensus, then IMHO committers will have to vote, as is true with open source projects in general.

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

[m.reza.rahman]

I agree with Dmitry and others. This is too important of a decision not to have an open vote that makes it as easy as possible for people to chime in on. In fact as I have stated elsewhere I believe this is the model that should be followed for almost all decisions to promote openness, inclusion and broader participation.

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: John Clingan <jcli...@redhat.com>

Date: 2/15/20 10:15 PM (GMT-05:00)

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

Subject: Re: [microprofile] Re: MicroProfile Working Group discussion - Push vs pull

Dmitry, the Hangout has been where we discuss issues and try to come to a consensus, sometimes with the aid of the google group in between hangouts. It's been that way since day one. There isn't a formal definition of consensus. Consensus has meant that everyone who participates in the Hangouts agrees to move forward. FYI, a bulk of those who participate in the hangouts, historically, have been spec authors, some marketing folks, committers, and contributors. We sometimes get community members, and we encourage them to participate.

Consensus has worked to date, but may not work here. If we can't reach consensus, then IMHO committers will have to vote, as is true with open source projects in general.

On Saturday, February 15, 2020 at 3:59:34 PM UTC-8, Dmitry Kornilov wrote:

IMO, consensus between 14 people present on the last Hangout doesn’t reflect a consensus in the MicroProfile community. I see many voices against separate WG. I didn’t count, but it easily can be more than 50% of all who posted. 

You need do a public voting and invite not only committers but also consumers.

-- Dmitry

сб, 15 февр. 2020 г. в 19:56, Rudy De Busscher <rdebu...@gmail.com>:

And in the case the consensus scenario doesn't work as we have now with the technical alignment and the WG discussion? Is consensus than the same as majority? How will that be determined?

Formal public voting will be the easiest, transparent and open-source project worthy solution.

Rudy

On Friday, 14 February 2020 16:36:08 UTC+1, John Clingan wrote:

Important edit: "voting no committers" should be "voting on committers" :-)

On Friday, February 14, 2020 at 7:33:56 AM UTC-8, John Clingan wrote:

There are two voting mechanisms within MicroPro"ltr">

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/3475450c-ff1a-4cdd-93fb-981d51d07d5d%40googlegroups.com.

[Mark Little]

Agreed. And whilst it's good and important to hear from all, only those who are formally recognised as contributors to the effort should get the vote, in the same was as pretty much every open source project of which I'm aware.

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/542925cb-7e07-4fbe-acaa-5402f450c8b2%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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/3475450c-ff1a-4cdd-93fb-981d51d07d5d%40googlegroups.com.

[Mark Little]

Perhaps it's worth reminding folks how things work (well) with MicroProfile since the outset, especially for those like Oracle, who didn't get involved at the time? I'm sure John Clingan or Kevin Sutter can do that in detail but the general approach has always been to leverage good open source project governance approaches. Now I know that some folks are new to the effort and may need to do some background reading or otherwise come up to speed on what has worked very well so far. That's fine ... it happens all of the time with open source projects where new people come to collaborate. But please stop trying to suggest that MP is somehow not being successful, that the processes don't work or are otherwise working against the community, or that there should be some demand for change. If change to processes or something else is something anyone wants to see then kick it off in an appropriate thread.

Now a little more inline ...

On Sat, Feb 15, 2020 at 11:59 PM Dmitry Kornilov <maid...@gmail.com> wrote:

IMO, consensus between 14 people present on the last Hangout doesn’t reflect a consensus in the MicroProfile community.

Consensus between the committers. As per good and successful open source projects there's often a way to focus voting so the project can make progress. Same thing happens in standards bodies. Go take a look at OASIS, W3C, OMG etc: there's always a way to narrow the voting (e.g., one company one vote) yet widen the ability to get feedback and have discussions.

 

I see many voices against separate WG. I didn’t count, but it easily can be more than 50% of all who posted. 

You need do a public voting and invite not only committers but also consumers.

This isn't a thread about WG! Please don't hijack threads, Dimitry.

Mark.

 

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

[Mark Little]

John, can we please take the discussions around process and WGs to their own unique threads and have them in parallel to the other topics we need to discuss in order to continue to evolve MicroProfile? Specifically, I do not want forward progress to be delayed or stopped whilst we debate some things which are orthogonal to technical direction.

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/66f8b70a-f144-4893-b530-ddb4944018e0%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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/98428417-f260-48e6-9184-6ed153552a89%40googlegroups.com.

[Steve Millidge]

However there isn't consensus with the committers. Rudy attends the call on behalf of the whole Payara team as the time of the call is not good for non-Americans and he has raised points against the proposal on calls.

This may have been how things operated in the past but now the dynamics have changed. The Payara team rightly or wrongly now feels that their views are ignored, piled on or steam rollered. There is now a dominance of committers from what is effectively one company so of course the status quo works for some. This may be the "open source way" and fine for a project. However it is not ideal governance for something that has a desire to create cross industry specifications.

The reason I talk about process rather than the technical merits of the proposal in the thread is that the proposal assumes a governance model of a totally independent MP with no regard for other initiatives like Jakarta EE or CN4J WGs. That base assumption is a step too far for me.

If we do go down that path then the proposal is logically correct and Jakarta should fork MP apis they want into the Jakarta namespace.

Steve

[m.reza.rahman]

With all due respect to everyone's sensibilities I agree with Steve. It is my sincere belief much of the end user community that I can reach also feels the same way. I hope the stakeholders try to understand this perspective. It is needed for something that should be of fundamental importance to a very broad ecosystem.

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: Steve Millidge <l33t...@gmail.com>

Date: 2/16/20 11:38 AM (GMT-05:00)

To: Eclipse MicroProfile <microp...@googlegroups.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/5b8dd253-dadb-4b8b-83ce-b236569e6708%40googlegroups.com.

[John Clingan]

I've moved the voting process thread to here. Let's continue push vs pull technical alignment here.

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/66f8b70a-f144-4893-b530-ddb4944018e0%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.

[Ondro Mihályi]

Hi,

As a committer, I'm definitely against taking major decisions during hangouts. And I'm against taking the decision about the proposal in this thread during a hangout unless a proper asynchronous voting happens before. If the decision is taken as John suggests I'm really worried about the direction of MicroProfile and the way how it operates.

The community hangout isn't a PMC or anything close to it. As a committer, I feel that my rights are ignored because I'm not able to join the hangouts regularly because the time doesn't suit me. However I watch most of the recordings and the mailing list, where I am also very active, and I can say I'm competent to cast my vote and I want to have a voice in decicions like this.

Ondro

[Mark Little]

Inline ...

On Sun, Feb 16, 2020 at 4:38 PM Steve Millidge <l33t...@gmail.com> wrote:

However there isn't consensus with the committers. Rudy attends the call on behalf of the whole Payara team as the time of the call is not good for non-Americans and he has raised points against the proposal on calls.

The time's not ideal for me but more due to the fact I have many meetings that conflict at that time anyway. However, I manage to get there now and then. But I do know where you're coming from so ... in general there are various options here:

(i) we can discuss a new time;

(ii) send an alternative representative, such as Rudy;

I'd be fine with either. However, we need to be cognisant of the fact that no time is likely to be good for everyone ... the JCP EC meeting has run at its time for many years and it's definitely not convenient for everyone, but we tend to have option (ii) work for us. Plus setting the same time and sticking to it does make it easier for people to plan either their own attendance or to get an alternate there.

 

This may have been how things operated in the past but now the dynamics have changed. The Payara team rightly or wrongly now feels that their views are ignored, piled on or steam rollered.

Well that's not good.

 

There is now a dominance of committers from what is effectively one company so of course the status quo works for some.

Well if you think it's one company you should be surprised by the amount of disagreements :)

 

This may be the "open source way" and fine for a project. However it is not ideal governance for something that has a desire to create cross industry specifications.

If you are suggesting changing the way MP works and move us away from using good open source governance approaches then that's a significant change and should definitely be it's own topic of discussion. I will point out that the goals of MP remain the same today as back in 2016 and that Payara was there at the start and agreeing. Now of course that doesn't mean people or vendors can't change their minds.

 

The reason I talk about process rather than the technical merits of the proposal in the thread is that the proposal assumes a governance model of a totally independent MP with no regard for other initiatives like Jakarta EE or CN4J WGs. That base assumption is a step too far for me.

No it doesn't assume that at all. It assumes good open source governance again :) Not sure if you listened to the recording but I'll repeat here what I said there as an example of why I think the pull model makes more sense. If you look at NetflixOSS, for example, they don't worry about whether or who may consume their projects as they evolve and release. Same goes for pretty much any project in the ASF. Eclipse Vert.x too works in that way. It's pretty standard for open source projects. If a consumer wants to stabilise on some version of, say, Vert.x they can do that and maybe even fork the project if the mainline is moving in a different direction. To reduce divergence of the forks they may try to push changes up to the mainline or pull changes down, but typically a complete rebase may be necessary eventually. Of course another way to ensure (prevent?) divergence would be for the "consuming" project folks to get involved in the upstream effort and help it evolve. In that way the consumer and consumed grow their relationship ... in a good and collaborative way. Now if the consumer doesn't care about changes to the consumed project, the one off fork may well be sufficient.

 

If we do go down that path then the proposal is logically correct and Jakarta  should fork MP apis they want into the Jakarta namespace.

That's certainly one way of accomplishing this. Another would be to take a version of MP or its specs and retain the namespace. This notion of having to change the namespace is something I still can't get my head around.

Mark.

 

Steve

--
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/5b8dd253-dadb-4b8b-83ce-b236569e6708%40googlegroups.com.

[Steve Millidge]

We send a representative, which is Rudy. However if decisions are driven by who is on the call other people can send multiple representatives and then the conversation can become skewed and dominated by one view point. Conference calls by their nature can become dominated by a view strident voices. This demonstrates the need for a working group as we mature. 

Consuming specifications is different to consuming a library jar like Netflix OSS or Vert.X. Specifications are by definition intended to have multiple diverse implementations and therefore the needs of these different implementations comes into play. For example it is unlikely that a consumer of Vert.X would need to support multiple versions of Vert.X simultaneously. Whereas if Jakarta EE 10 incorporated MP 3.0 apis  but MP 4.0 is released with breaking changes with no consideration of consumers then it becomes very difficult for a product to support Jakarta EE 10 and MP 4.0 due to the requirement to support MP 3.0 and MP 4.0 simultaneously. This is the point Rudy brought up on our behalf on the call.

This is why I talk about moving namespace if Jakarta EE wishes to consume a MP api. If Jakarta EE 10 standardises some MP 3.0 apis and moves them into the jakarta namespace the scenario above becomes much easier to manage. Two independent initiatives, consuming specs in each other's namespace, with different backward compatibility goals, would become a nightmare to attempt to support both and likely cause immense confusion for developers. 

Maybe as stated above this is just a problem for Payara and OpenLiberty however adopting a strategy that makes it difficult to support both Jakarta EE and MP in the same platform has the potential to reduce the number of implementations and therefore the significance and popularity of MP among EE developers who are an obvious target for uptake of MP. 

If in the worst case the number of MP specification implementations tends towards 1 then you don't have a specification you have just another microservices framework.

Steve

 

Mark.

 

Steve

--
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.

[Mark Little]

Inline ...

On Mon, Feb 17, 2020 at 2:26 PM Steve Millidge <l33t...@gmail.com> wrote:

We send a representative, which is Rudy. However if decisions are driven by who is on the call other people can send multiple representatives and then the conversation can become skewed and dominated by one view point. Conference calls by their nature can become dominated by a view strident voices. This demonstrates the need for a working group as we mature. 

I'd assume on the call can call for a specific vote via email if they feel the representation on that call isn't representative. I'm sure John or Kevin can confirm, but I'm pretty sure that's why after the call last week we agreed to John sending a summary and asking for input. So ... job done!

 

Consuming specifications is different to consuming a library jar like Netflix OSS or Vert.X.

s/Vert.X/Vert.x/p

 

Specifications are by definition intended to have multiple diverse implementations and therefore the needs of these different implementations comes into play. For example it is unlikely that a consumer of Vert.X would need to support multiple versions of Vert.X simultaneously. Whereas if Jakarta EE 10 incorporated MP 3.0 apis  but MP 4.0 is released with breaking changes with no consideration of consumers then it becomes very difficult for a product to support Jakarta EE 10 and MP 4.0 due to the requirement to support MP 3.0 and MP 4.0 simultaneously. This is the point Rudy brought up on our behalf on the call.

This is why I talk about moving namespace if Jakarta EE wishes to consume a MP api. If Jakarta EE 10 standardises some MP 3.0 apis and moves them into the jakarta namespace the scenario above becomes much easier to manage. Two independent initiatives, consuming specs in each other's namespace, with different backward compatibility goals, would become a nightmare to attempt to support both and likely cause immense confusion for developers. 

Well there are other possible approaches to supporting different implementations, e.g., OSGi.

 

Maybe as stated above this is just a problem for Payara and OpenLiberty however adopting a strategy that makes it difficult to support both Jakarta EE and MP in the same platform has the potential to reduce the number of implementations and therefore the significance and popularity of MP among EE developers who are an obvious target for uptake of MP. 

OK but as discussed on the call (recording available) the point of the pull approach instead of push was that MP doesn't know about all potential consumers. Jakarta is one but there could be others and if we do something specific for one it may impact how we can approach others. And at the moment, the pull approach is the safest (allows for widest possible adoption) as it's essentially the do-nothing (within MP) option.

 

If in the worst case the number of MP specification implementations tends towards 1 then you don't have a specification you have just another microservices framework.

Well there's also another subtlety inherent within the pull model which may be too subtle as I don't believe anyone has mentioned it yet: if there's a pull from, say, Jakarta EE, and the people behind the innovation decide to move there to continue its development then the "problem" of forks goes away. Similar to what happened between Hudson and Jenkins. And in good open source governance, there's nothing we can or should do to prevent this.

Mark.

 

Steve

 

Mark.

 

Steve

--
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/5b8dd253-dadb-4b8b-83ce-b236569e6708%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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/0326ac7e-55e0-4af8-b69c-b8774fb0d54f%40googlegroups.com.

[John Clingan]

Per the Live Hangout Working Group discussion yesterday,  lets comment on the text of the comments:

https://docs.google.com/document/d/1VQ5cvzhVhKYr27FKC1tVmf081eGLSNiuX-dhQ2BxItc

Note,  this is a GREAT thread to have the broader conversation instead of the doc comments. Doc comments get hidden (resolved)  over time. Let's see how it goes.