Please all stop putting fuel into the fire. LieGrue, strub
> Am 13.02.2018 um 08:48 schrieb Jean-Louis Monteiro <[email protected]>: > > Instead of shooting to someone or start arguing. Simply asking would take > all misunderstand off and avoid this disgusting mess. > > Le 13 févr. 2018 08:33, "Mark Struberg" <[email protected]> a > écrit : > >> +1 words - and especially brief once as emails - are just a mapping from >> the reality to some 'transport mechanism' (Claude Shannon sender theoreme >> anyone?). >> And of course each 'map' is a huge simplification from the reality and >> thus prone to be misinterpreted. >> >> The important part here is that those clashes bring up some difference in >> view. >> And yes, I also think this has nothing to do with immature or childish. We >> are all just passionate. >> So the first very important step is to identify the pain point. >> >> For Romain and me, etc is to avoid duplication of work which already got >> done in other ASF projects. >> And to not have those modules hardcoded bound to the TomEE Application >> Server but to be reusable for other projects. >> Please note that I'm talking about the Appliation Server only and not >> about the TomEE project as governance body. >> >> I also had an important lesson in the 90s: >> >> If you have a problem >> 1.) solve it >> 2.) if you cannot solve it, live with it >> 3.) if you cannot live with it, leave it. >> >> More generally: >> There are some points which totally doesn't matter to someone. >> There are other points which we would love to see a certain outcome, but >> we would also perfectly accept a compromise. >> And is also a category of points where we simply cannot live with a >> compromise. Or where we would simply stop being part of it. >> >> In the current situation it's pretty easy. NONE of the cases fits. >> It was simply a misunderstanding. >> Andy wanted to commit samples and integrate mp-config to TomEE. >> This is perfectly fine, but the commit comment and the location was very >> easy to get misinterpreted. >> And that's exactly what happens. >> >> That's like you forbid your daughter to use your car and then she snatches >> your keys. >> You shout at her, but only after she bursts out in tears you find out that >> she only wanted to wash your car as a birthday present... >> >> And now back to work pretty please ;) >> >> LieGrue, >> strub >> >>> Am 13.02.2018 um 07:38 schrieb dsh <[email protected]>: >>> >>> All, >>> >>> I followed what David calls "incidents" or "childish" quite closely in >> the >>> past. Why? Cause such situations are quite familiar to me. I've been >> there >>> thousands of times and what I can tell for granted is that non of these >>> situations are neither "incidents" nor "childish". >>> >>> As a matter of fact each individual has a certain believe system on one >>> hand and on the other hand lives on his/her own island. The latter I use >> as >>> an explanation for the fact that we all have our own perception of what >> we >>> think reality is and it usually isn't congruent with the perception of >>> others. If either your believe systems are conflicting or your perception >>> of what you think is reality are clashing, you usually have such >>> "incidents". >>> >>> That said I learned the hard way that usually you are not fighting, like >> in >>> this case, about backed out code but it's usually something >> inter-personal. >>> What makes me wondering especially if I think about all the Twitter and >>> Facebook posts where I see you guys hanging out together is, that such, >> as >>> I suspect it inter-personal conflicts, erupt on the mailing list or over >>> code commits, where my naive understanding is, that you could talk >>> face-to-face to nail down what really drives you crazy. >>> >>> What I learned is that it doesn't quite help, neither from the >> perspective >>> of somebody that is involved, nor from the perspective of somebody who >> is a >>> leader to finger point or to call out individuals. In the end you turned >>> this into a mess and thus you have to fix it TOGETHER. If necessary you >>> could even pull in a coach from outside. I for myself applied for a coach >>> back in 2015. It's not a silver bullet and does not fix everything you >>> screwed up in the past but it sometimes helps to have somebody with a >>> neutral view and another opinion. >>> >>> In the end my perception of reality on my little island is that you all >>> bond a very strong team. I saw and worked with teams that were no real >> team >>> in the end. In your case I don't have such a perception and thus I >> believe >>> that you get this sorted out in a sustainable manner. Take it as a growth >>> opportunity! >>> >>> Cheers >>> Daniel >>> >>> On Tue, Feb 13, 2018 at 6:33 AM, David Blevins <[email protected]> >>> wrote: >>> >>>> Ok, community, we have to have another quick talk and then hopefully we >>>> can go back to being awesome. >>>> >>>> This thread got very negative and bares a striking resemblance to the >>>> "Suffocating Development Environment" thread from the June 27th >> incident. >>>> Yes, I've written about it enough times in the board reports that I have >>>> the date memorized. What I've written is mostly positive and been >> praised >>>> by the board for our handling of a hard situation. You're all making a >>>> liar out of me. :) >>>> >>>> I was delicate in the first situation, but now I have to be a bit more >>>> direct. >>>> >>>> >>>> In the June 27th incident we had Andy committing code, Romain reverting >>>> it, the two exchanging insults for one hour till Andy quit complaining >> that >>>> he's working in his spare time implies Romain is killing the project. >> Mark >>>> joins attempting to take some heat off of Romain. Jon joins attempting >> to >>>> be as neutral as possible. In the end both Mark and Jon apologize. >> Andy's >>>> code stays reverted. >>>> >>>> In this incident Andy committed code. Mark and Romain begin arguing. >>>> Insults are exchanged for one hour till Andy quits complaining that he's >>>> working in his spare time and implies Romain is killing the project. >> Jon >>>> joins attempting to be as neutral as possible. In the end both Mark and >>>> Jon apologize. Andy's code stays reverted. This time it's all >> Tomitribe's >>>> fault. >>>> >>>> >>>> Am I the only one to notice a pattern? That pattern is not one person's >>>> fault. The pattern is we are behaving like children. >>>> >>>> >>>> This will not get better if each of us is expecting the other guy to >>>> change. If your only response to this email is find flaws in others, I >>>> guarantee nothing will get better. >>>> >>>> Mark, you got there in the end which is great. You pointed out >> something >>>> you could have done better and something Andy could do better. That's >> the >>>> right pattern. People are much more willing to accept feedback when >> they >>>> see you're also willing to accept it. >>>> >>>> We need to get there sooner next time and we need more than one person >>>> doing it. >>>> >>>> >>>> So with all that said, how do we turn this into an awesome learning >>>> experience that makes us stronger? >>>> >>>> >>>> >>>> -David >>>> >>>> >>>> >>>>> On Feb 12, 2018, at 11:22 AM, Andy Gumbrecht <[email protected] >>> >>>> wrote: >>>>> >>>>> Added project stubs: https://github.com/apache/ >>>> tomee/tree/master/microprofile >>>>> >>>>> Andy. >>>>> >>>>> >>>>> On 05/02/18 11:17, Jean-Louis Monteiro wrote: >>>>>> Hi, >>>>>> >>>>>> Ok thanks guys. >>>>>> @Rudy, you are most welcome :) >>>>>> >>>>>> -- >>>>>> Jean-Louis Monteiro >>>>>> http://twitter.com/jlouismonteiro >>>>>> http://www.tomitribe.com >>>>>> >>>>>> On Fri, Feb 2, 2018 at 11:39 AM, Rudy De Busscher < >>>> [email protected]> >>>>>> wrote: >>>>>> >>>>>>> I think it is a very important spec, also for non-microprofile >>>>>>> implementations as it can enhance the interoperability of all >> servers. >>>>>>> >>>>>>> I'm also very interested in the implementation (and want to help a >> bit >>>> with >>>>>>> it also :) ) >>>>>>> >>>>>>> regards >>>>>>> Rudy >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 2 February 2018 at 11:23, Mark Struberg <[email protected] >>> >>>>>>> wrote: >>>>>>> >>>>>>>> To clarify this even further: >>>>>>>> The Geronimo Server is now officially dead. >>>>>>>> But the Geronimo project is not. It alredy contains quite a few >>>> modular >>>>>>>> parts which are reused in many ASF projects and also outside. >>>>>>>> Examples is the geronimo-transaction-manager, geronimo-javamail, >>>>>>>> geronimo-config, xbean-finder, etc >>>>>>>> >>>>>>>> Of course it would probably make sense to fold those 2 projects >>>> together, >>>>>>>> as already discussed in the past. >>>>>>>> I'm still all open to it, but I have an important criterium to >> fulfil: >>>>>>>> If we move those portable parts to TomEE, then this would mean that >>>> TomEE >>>>>>>> would become an 'Umbrella project'. >>>>>>>> And further that we would need a new name for those portable parts. >>>>>>>> They would effectively be mainatained by the TomEE community (which >>>> has a >>>>>>>> big overlap with Geronimo anyway) but those parts must clearly be >>>>>>>> recognized separately from TomEE. >>>>>>>> >>>>>>>> Otherwise people will assume that those parts only work within >> TomEE - >>>>>>>> where in reality they would even work on WildFly or Liberty, etc. or >>>>>>> even a >>>>>>>> naked Tomcat. >>>>>>>> Got me? >>>>>>>> >>>>>>>> We might e.g. brand them as 'TomEE Geronimo Spare Parts Department' >> :) >>>>>>>> >>>>>>>> LieGrue, >>>>>>>> strub >>>>>>>> >>>>>>>> PS: I'd also love to keep the org.apache.geronimo package name to >> ease >>>>>>>> backward compatibility. >>>>>>>> >>>>>>>> >>>>>>>>> Am 02.02.2018 um 11:08 schrieb Romain Manni-Bucau < >>>>>>> [email protected] >>>>>>>>> : >>>>>>>>> >>>>>>>>> 2018-02-02 11:05 GMT+01:00 Otávio Gonçalves de Santana < >>>>>>>>> [email protected]>: >>>>>>>>> >>>>>>>>>> Guys, I have a question: >>>>>>>>>> >>>>>>>>>> Why not a project to each implementation? >>>>>>>>>> >>>>>>>>> this is the case but geronimo is used as an umbrella project. >>>>>>>>> >>>>>>>>> >>>>>>>>>> This way I can use just a specific if I want also. >>>>>>>>>> >>>>>>>>> exactly the goal and user usage AFAIK ;) >>>>>>>>> >>>>>>>>> long story short: we learnt from the past errors and since always >> the >>>>>>>> same >>>>>>>>> people work on these projects it is better to not split it accross >> N >>>>>>>>> communities since >>>>>>>>> it leads to a lot of efforts for these people. Having a single >>>> umbrella >>>>>>>>> project with N subprojects reduces the administrative work etc and >>>>>>>> enhance >>>>>>>>> the projects productivity. >>>>>>>>> >>>>>>>>> >>>>>>>>>> On Fri, Feb 2, 2018 at 7:44 AM, Romain Manni-Bucau < >>>>>>>> [email protected]> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Hi JL, >>>>>>>>>>> >>>>>>>>>>> Microprofile apache effort is hosted in geronimo and John already >>>>>>> spoke >>>>>>>>>>> about it I think. Would probably saner to keep it all at the same >>>>>>> place >>>>>>>>>> for >>>>>>>>>>> the foundation. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Romain Manni-Bucau >>>>>>>>>>> @rmannibucau <https://twitter.com/rmannibucau> | Blog >>>>>>>>>>> <https://rmannibucau.metawerx.net/> | Old Blog >>>>>>>>>>> <http://rmannibucau.wordpress.com> | Github <https://github.com/ >>>>>>>>>>> rmannibucau> | >>>>>>>>>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book >>>>>>>>>>> <https://www.packtpub.com/application-development/java- >>>>>>>>>>> ee-8-high-performance> >>>>>>>>>>> >>>>>>>>>>> 2018-02-02 9:39 GMT+01:00 Jean-Louis Monteiro < >>>>>>>> [email protected] >>>>>>>>>>> : >>>>>>>>>>> >>>>>>>>>>>> Hi all, >>>>>>>>>>>> >>>>>>>>>>>> I was wondering if we could have the Microprofile JWT >> implemented >>>> in >>>>>>>>>>> TomEE. >>>>>>>>>>>> What do you think? >>>>>>>>>>>> >>>>>>>>>>>> I was reading the spec and I'd like to contribute that in. >>>>>>>>>>>> >>>>>>>>>>>> Jean-Louis >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> Jean-Louis Monteiro >>>>>>>>>>>> http://twitter.com/jlouismonteiro >>>>>>>>>>>> http://www.tomitribe.com >>>>>>>>>>>> >>>>>>>> >>>>> >>>>> -- >>>>> Andy Gumbrecht >>>>> https://twitter.com/AndyGeeDe >>>>> http://www.tomitribe.com >>>>> https://www.tomitribe.io >>>>> >>>>> >>>>> Ubique >>>>> >>>> >>>> >> >>
