| Re: [jakarta.ee-community] Fork Eclipse MicroProfile Configuration as Jakarta Configuration. |
Werner
If I understand correctly, option 3 is already allowed. Anyone can
join the MP community and help out with the spec; it's certainly not
forbidden in any way I can think of. We don't need a WG to make it
happen. Anyone can apply to be a committer as well.
It just has to be understood that right now we're essentially running
on a unanimous consensus model, which might or might not scale to
large numbers of participants. But, as the saying goes: you don't
know if you don't try.
On Mon, Apr 6, 2020 at 9:42 AM Werner Keil <werner.keil@xxxxxxxxx> wrote:
>
> Roberto,
>
> Thanks for the bullet points.
>
> Especially about 1 or 2 it is up to the Jakarta EE committees, mostly Steering and Specification Committee and likely other groups like the PMC to clarify once and for all, if a mix of namespaces inside a spec was acceptable or not.
> That shall clarify the expectations and requirements on the JEE side.
>
> Depending on the outcome once there is a MP WG (assuming there shall be one, the last voices and statements were along those lines) that WG can take it further to allow 3.
>
> Werner
>
>
>
>
> On Mon, Apr 6, 2020 at 4:10 PM Roberto Cortez <radcortez@xxxxxxxxx> wrote:
>>
>> Hi,
>>
>> I've been following the conversation very closely since I'm working a lot in the MP Config space.
>>
>> I think we need to recenter the discussion in the technical aspects. Configuration might be a very stable and known space, but that doesn't mean that MP Config is itself there yet.
>>
>> I invite any of you to visit the issue tracker of MP Config:
>> https://github.com/eclipse/microprofile-config/issues
>>
>> As you can see, there are a lot of things going on right now. Yes, we could push MP Config to Jakarta in its current state, but there are still many open issues/questions/use cases not covered.
>>
>> So we have several options here:
>>
>> 1. Jakarta EE may indeed fork and use the current state of MP Config (knowing there is still a lot of things missing). It can either be kept in that state or/and fill the gaps in the future (while the same kind of work will be happening in MP Config).
>>
>> 2. MP Config does move to Jakarta EE, knowing that maybe it is not stable enough and gaps will need to be filled along the way. MP Config community could move to Jakarta and provide the gaps over there. Are we able to do it in a timely manner?
>>
>> 3. Both Jakarta and MP communities work together in MP Config to close the gaps and prepare it to be adopted by Jakarta EE in the future.
>>
>> 4. Something else?
>>
>> Cheers,
>> Roberto
>>
>> On 6 Apr 2020, at 15:05, reza_rahman <reza_rahman@xxxxxxxxx> wrote:
>>
>> From what I can tell, most people are seeing this as a last resort. I certainly do.
>>
>> For the folks I talk to, standardization is definitely a very important consideration. Indeed the desire to utilize a credible open standard (with everything that means such as cohesion, vendor neutrality, governance, process, compatibility, stability, backwards compatibility) is often the driving reason to utilize, advocate for and contribute to this technology set. Otherwise honestly, there are better options if innovation and feature set is the only considerations. It is certainly not just a matter of what banner something is under.
>>
>> 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: Jason Greene <jason.greene@xxxxxxxxxx>
>> Date: 4/6/20 9:46 AM (GMT-05:00)
>> To: Jakarta EE community discussions <jakarta.ee-community@xxxxxxxxxxx>
>> Subject: Re: [jakarta.ee-community] Fork Eclipse MicroProfile Configuration as Jakarta Configuration.
>>
>> I think it’s gotta be more than frivolous, it's really a measure of last resort, since you divide the community. The folks participating on the MP version will be unlikely to participate on the fork, and vice versa.
>>
>> That said the justifications to fork don’t seem particularly strong, and seem to amount to just what banner the project is under.
>>
>> On Apr 6, 2020, at 7:32 AM, reza_rahman <reza_rahman@xxxxxxxxx> wrote:
>>
>> I think the main at least somewhat technical point appears to be that forking should not be pursued frivolously. I very much doubt anyone is doing that. It appears in fact that the alignment discussions has been given more than due consideration for some time now, certainly during the recent MicroProfile pull vs push vote.
>>
>> 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: Ondro Mihályi <ondrej.mihalyi@xxxxxxxxx>
>> Date: 4/6/20 7:07 AM (GMT-05:00)
>> To: Jakarta EE community discussions <jakarta.ee-community@xxxxxxxxxxx>
>> Subject: Re: [jakarta.ee-community] Fork Eclipse MicroProfile Configuration as Jakarta Configuration.
>>
>> I don't understand, Mark. Did you mean there IS or IS NOT an inherent right to fork MP by JEE or that there is?
>>
>> I believe that since MP specs are Apache licenced, JEE has an inherent right to fork them. Or did you mean something else?
>>
>> Dňa po 6. 4. 2020, 13:01 Mark Little <mlittle@xxxxxxxxxx> napísal(a):
>>>
>>> Hi Ondro.
>>>
>>> Not sure if you read my longer email earlier today but let me summarise one point: it's for the Jakarta EE community to decide whether or not to fork *any* other open source project, not just MP, and take the consequences of that on themselves. There is no inherent right for Jakarta EE to do this with MP just as there's no inherent right for MP to fork any of the Jakarta EE specs (which it has not done).
>>>
>>> Mark.
>>>
>>> On Mon, Apr 6, 2020 at 11:57 AM Ondro Mihályi <ondrej.mihalyi@xxxxxxxxx> wrote:
>>>>
>>>> Hi, Mark,
>>>>
>>>> I appreciate that your intension with yhe Pull model wasn't to suggest forking. But the text approved by boting explicitly mentions forking as an option. So don't be surprised that some people in JakartaEE consider it as an option. If we want to change that, MP should either reconsider that Pull statement or provide more detailed explanation for it.
>>>>
>>>> Dňa po 6. 4. 2020, 11:56 Mark Little <mlittle@xxxxxxxxxx> napísal(a):
>>>>>
>>>>> Rudy, I was the one who first proposed the pull versus push model at the MP hangout in February and I definitely did not use the fork at the time or include it in any text. It is not necessary to fork any project, whether it’s a spec based project or one which produces libraries, for instance, when becoming dependant upon it. Collaborating communities can do just that: collaborate and embed.
>>>>>
>>>>> Mark.
>>>>>
>>>>>
>>>>> On 5 Apr 2020, at 08:44, Rudy De Busscher <rdebusscher@xxxxxxxxx> wrote:
>>>>>
>>>>> Can everyone who voted for PULL, stop complaining against the Jakarta people for exactly doing what you have voted for.
>>>>>
>>>>> The word fork was removed last minute from the pull text but it was always part of it during the discussions during months and the intention. But this downstream project is exactly doing what is in the PULL text, defining the lifecycle, compatibility requirements and namespace.
>>>>>
>>>>> And don't start about having 2 different hats. There is only 1 world, 1 reality in which Jakarta does exactly what is needs to do based on the outcome of the PULL vs PUSH vote.
>>>>>
>>>>> The fork is the only viable solution if vendors want to keep combining Jakarta EE and MicroProfile in one product when some of the MP specs are used by Jakarta Specs.
>>>>>
>>>>>
>>>>>
>>>>> On Fri, 3 Apr 2020 at 20:11, David Lloyd <david.lloyd@xxxxxxxxxx> wrote:
>>>>>>
>>>>>> You are simply factually wrong in this regard. You're defining
>>>>>> "caring about compatibility" as being synonymous with "forcing strict
>>>>>> compatibility rules", when this is not true in any respect.
>>>>>>
>>>>>> I voted "Pull" because the chief goal of MP ought to be to meet user
>>>>>> needs effectively and quickly, even if that means (in the worst case)
>>>>>> bumpy compatibility at first. As I said, compatibility is a quality
>>>>>> measure (just one of many) and it arises from a good specification.
>>>>>> Making a specification be compatible doesn't make it good or useful.
>>>>>> It's far better to add compatibility restrictions *after* the
>>>>>> specification is already stable, rather than to add such restrictions
>>>>>> to a specification that is still rapidly developing (thereby greatly
>>>>>> diminishing its usefulness in the name of stamping a logo on it in the
>>>>>> short term). This is (IMO) a good indicator of when it makes sense to
>>>>>> "graduate" a spec into Jakarta. The consumers of Jakarta are looking
>>>>>> for long term stability, and that comes from quality, not from a
>>>>>> compatibility contract.
>>>>>>
>>>>>> Voting "Push" would have done nothing to improve the quality of
>>>>>> specifications and would have obstructed the process of cross-vendor
>>>>>> standardization - an already inherently politically and socially
>>>>>> obstructive process. It was a very cynical option IMO.
>>>>>>
>>>>>> On Fri, Apr 3, 2020 at 12:55 PM Werner Keil <werner.keil@xxxxxxxxx> wrote:
>>>>>> >
>>>>>> > Everyone who voted for this "Pull" option voted against compatibility and supporting it, not sure how many votes Red Hat got there and who was eligible but the majority voted for the "I don't care about compatibility" option, did you vote for "Push"?
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> > On Fri, Apr 3, 2020 at 7:33 PM David Lloyd <david.lloyd@xxxxxxxxxx> wrote:
>>>>>> >>
>>>>>> >> AFAICT the only people claiming that MP doesn't care about
>>>>>> >> compatibility are MP detractors. MP doesn't *prioritize*
>>>>>> >> compatibility, but I for one *care* about it quite a lot. When your
>>>>>> >> first priority is meeting use cases, then compatibility becomes a
>>>>>> >> quality measure: the easier it is to retain compatibility in the face
>>>>>> >> of new use cases, the more likely it is that the specification is
>>>>>> >> already useful for use cases beyond those originally imagined. The
>>>>>> >> more useful a specification is, the wider its adoption.
>>>>>> >>
>>>>>> >> On Fri, Apr 3, 2020 at 12:18 PM Werner Keil <werner.keil@xxxxxxxxx> wrote:
>>>>>> >> >
>>>>>> >> > And especially one claiming it doesn't care about compatibility or the consumers of its frameworks or APIs while the other by definition has to.
>>>>>> >> >
>>>>>> >> > Werner
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >
>>>>>> >> > On Fri, Apr 3, 2020 at 7:11 PM Steve Millidge (Payara) <steve.millidge@xxxxxxxxxxx> wrote:
>>>>>> >> >>
>>>>>> >> >> Hi David,
>>>>>> >> >>
>>>>>> >> >> I agree nobody wants to duplicate effort. Which is why it is non-sensical to have two separate specification bodies defining specifications which are intertwined as these discussions on both sides demonstrate.
>>>>>> >> >>
>>>>>> >> >> Steve
>>>>>> >> >>
>>>>>> >> >> -----Original Message-----
>>>>>> >> >> From: jakarta.ee-community-bounces@xxxxxxxxxxx <jakarta.ee-community-bounces@xxxxxxxxxxx> On Behalf Of David Lloyd
>>>>>> >> >> Sent: 03 April 2020 16:49
>>>>>> >> >> To: Jakarta EE community discussions <jakarta.ee-community@xxxxxxxxxxx>
>>>>>> >> >> Subject: Re: [jakarta.ee-community] Fork Eclipse MicroProfile Configuration as Jakarta Configuration.
>>>>>> >> >>
>>>>>> >> >> On Fri, Apr 3, 2020 at 9:56 AM Werner Keil <werner.keil@xxxxxxxxx> wrote:
>>>>>> >> >> >
>>>>>> >> >> > All of these are defined by standard bodies with strong compatibility requirements like W3C or the JCP.
>>>>>> >> >> >
>>>>>> >> >> > The namespace is not so much a problem as the "Not My Problem" attitude the MP stakeholders expressed in their vote for the option called "Pull". That is even a stronger argument against using a feature like MP Config as is instead of a "fork" or writing something heavily inspired by it from scratch in Jakarta EE.
>>>>>> >> >>
>>>>>> >> >> Who would do the work? We're rapidly innovating in MP Config right now, learning a lot about the problem space and processing real user feedback, and applying that knowledge in a way that can be consumed today. If you fork, you're going to end up with probably a separate body of people (where will these people come from?), developing a separate piece of software from scratch which, instead of being based on working and useful implementations, is top-down designed and has no initial implementations - discarding that learning process just to spite MP out of impatience AFAICT. It seems silly to me.
>>>>>> >> >>
>>>>>> >> >> If the bar for Jakarta EE is stability, you can't clear that bar by crapping out some code and calling it "stable", no matter how brilliant you are. It has to be proven in the laboratory of the real world - an iterative process. MP Config is going through that process right now, in fact, and rapid innovation is the direct result of that.
>>>>>> >> >> We're not breaking things for fun, and in fact we put forth some effort to not break things anyway (despite being allowed to). Perhaps there will be a time where most people are mostly happy with it and few new use cases arise, rendering the specification mostly quiescent, but until that time, anything you do to call the field of standardized configuration in Java "stable" will effectively be a lie, just to check a box. Such lies do little to enhance the reputation of specification bodies which perpetuate them.
>>>>>> >> >>
>>>>>> >> >> > Not giving a damn about compatibility requirements means, Jakarta EE probably would have to fork the TCK for such MP feature anyway because if the project suddenly decides to run the TCK with Spock or JUnit 5 instead of TestNG while the Jakarta EE platform has other foundations of its TCKs, then Jakarta EE might as well just fork the whole of it instead of bothering with a TCK fork or trying to integrate it somehow without support by the authors.
>>>>>> >> >>
>>>>>> >> >> I guess it depends on how much you enjoy doing busy work. I for one really dislike doing it; any time spent working on a (possibly
>>>>>> >> >> inferior) parallel specification to one that is in wide use is time wasted, to me; I can only imagine that my co-collaborators on MP Config feel similarly. Who would be left to work on the specification when all of the experienced engineers don't want to do it? What kind of specification would that be?
>>>>>> >> >>
>>>>>> >> >> It's far more rational to let MP Config continue to do the "dirty work" of figuring out what works and what doesn't work, and then revisit the question at a more appropriate time. Consuming MP Config could be a far more attractive option in, say, 12-18 months time.
>>>>>> >> >> Moving it wholesale to Jakarta might similarly be a more reasonable option at that time. It's better than spending 12-18 months arguing over a new specification anyway - how tiresome that would be.
>>>>>> >> >> --
>>>>>> >> >> - DML
>>>>>> >> >>
>>>>>> >> >> _______________________________________________
>>>>>> >> >> jakarta.ee-community mailing list
>>>>>> >> >> jakarta.ee-community@xxxxxxxxxxx
>>>>>> >> >> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
>>>>>> >> >> _______________________________________________
>>>>>> >> >> jakarta.ee-community mailing list
>>>>>> >> >> jakarta.ee-community@xxxxxxxxxxx
>>>>>> >> >> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
>>>>>> >> >
>>>>>> >> > _______________________________________________
>>>>>> >> > jakarta.ee-community mailing list
>>>>>> >> > jakarta.ee-community@xxxxxxxxxxx
>>>>>> >> > To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
>>>>>> >>
>>>>>> >>
>>>>>> >>
>>>>>> >> --
>>>>>> >> - DML
>>>>>> >>
>>>>>> >> _______________________________________________
>>>>>> >> jakarta.ee-community mailing list
>>>>>> >> jakarta.ee-community@xxxxxxxxxxx
>>>>>> >> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
>>>>>> >
>>>>>> > _______________________________________________
>>>>>> > jakarta.ee-community mailing list
>>>>>> > jakarta.ee-community@xxxxxxxxxxx
>>>>>> > To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> - DML
>>>>>>
>>>>>> _______________________________________________
>>>>>> jakarta.ee-community mailing list
>>>>>> jakarta.ee-community@xxxxxxxxxxx
>>>>>> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
>>>>>
>>>>> _______________________________________________
>>>>> jakarta.ee-community mailing list
>>>>> jakarta.ee-community@xxxxxxxxxxx
>>>>> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
>>>>>
>>>>>
>>>>> ---
>>>>> Mark Little
>>>>> mlittle@xxxxxxxxxx
>>>>>
>>>>> 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)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> jakarta.ee-community mailing list
>>>>> jakarta.ee-community@xxxxxxxxxxx
>>>>> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
>>>>
>>>> _______________________________________________
>>>> jakarta.ee-community mailing list
>>>> jakarta.ee-community@xxxxxxxxxxx
>>>> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
>>>
>>> _______________________________________________
>>> jakarta.ee-community mailing list
>>> jakarta.ee-community@xxxxxxxxxxx
>>> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
>>
>> _______________________________________________
>> jakarta.ee-community mailing list
>> jakarta.ee-community@xxxxxxxxxxx
>> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
>>
>>
>> _______________________________________________
>> jakarta.ee-community mailing list
>> jakarta.ee-community@xxxxxxxxxxx
>> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
>>
>>
>> _______________________________________________
>> jakarta.ee-community mailing list
>> jakarta.ee-community@xxxxxxxxxxx
>> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
>
> _______________________________________________
> jakarta.ee-community mailing list
> jakarta.ee-community@xxxxxxxxxxx
> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
--
- DML
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community