Hi - Apologies for not following the thread this week.
I suggest that everyone have a Royale Free weekend. Think about the best resolution to this situation Sunday evening after relaxing. Everyone should be willing to compromise. Try to send only a few emails on Monday. Let the world revolve. Carlos I know you are passionate! Your heart is strong. Regards, Dave Sent from my iPhone > On May 11, 2018, at 11:11 AM, Carlos Rovira <[email protected]> wrote: > > Hi Dave, > > I talked about to left all cold for this weekend, but Harbs responded, and > I feel I want to express him that his response was cold. > Seems Alex, has taken another totally different approach. > > the problem Dave, is that the change was done the past Friday, and from > since we made many things, published public blog post, update all past blog > posts code to match new ones, and so... maybe for that reason I was not in > favor of a roll back, and since Jewel needs that kind of changes, I even > though that was more easy to go forward, and change things from the new > state to something we all want. > > 2018-05-11 19:50 GMT+02:00 Dave Fisher <[email protected]>: > >> Hi - >> >> I was going to write a similar message to Alex’s, but shorter and with a >> different tone. >> >> When making breaking changes it is best to let people know in advance. If >> you are in hurry then make a branch or unmerged PR immediately. Once you >> have code in hand then you can have a discussion about whether the >> community accepts your new approach. Who knows, the community might decide >> its good. I know that your work on Jewel is good for the larger Royale >> community. >> >> Another rule to take is that when discussions heat up, the best thing to >> do is to slow your email output to one or two a day. Let the world revolve… >> (I call this the Sam Ruby rule since I first learned it from him several >> years ago.) >> >> HTH, >> Dave >> >>> On May 11, 2018, at 9:38 AM, Alex Harui <[email protected]> >> wrote: >>> >>> Carlos, >>> >>> Fundamentally, the misunderstanding is that you think you have provided >> technical reasons and nobody else thinks so. It appears to me and others >> that you are using a bug to justify a non-scalable coding pattern that is >> definitely not DRY. >>> >>> I'm not sure I want to discuss the technical aspects of your changes in >> this thread. I left what I think is a concise question for you in the >> original thread. I suggest that we continue the discussion in that thread. >>> >>> IMO, consensus is an important value at Apache. The consensus is that >> the approach you are taking is not correct. And socially, the response to >> consensus saying that the approach you are taking is not correct should be >> "oops, let me fix it quickly" or "oops, I'll revert and put it in a >> branch". No one individual is being a dictator here. There are four of us >> who don't think your commit was the right thing, and nobody besides you who >> thinks it is right. If you are not open to the possibility that your >> approach is not correct, then we definitely have a problem on our hands. >> Individuals who cannot build consensus but still think they are right are >> having trouble communicating, or are problem personalities. >>> >>> My 2 cents, >>> -Alex >>> >>> On 5/11/18, 6:55 AM, "[email protected] on behalf of Carlos >> Rovira" <[email protected] on behalf of [email protected]> >> wrote: >>> >>> Thanks Upayavira, >>> >>> for you thought, I think very well brought. I'm fact think that most >> of the >>> things you described was happening here. I tried to do my best to >> explain >>> lots of time with different words the reasons, maybe much people here >> are >>> very busy an some explanations was read "from above". I'm for >> explaining >>> more times if is needed, but as well I think we all need in the point >> that >>> no body is in posession of truth and that we can get a consensus with >> a >>> mixture of all the points. I'm more on this. I think this is not a >> "one >>> thing or the other", in this conflict, like in the rest we can have, I >>> always target for a mixture that makes all people happy, at least in >> this >>> conctrete problem we can get to it. >>> >>> Thanks >>> >>> >>> 2018-05-11 15:45 GMT+02:00 Upayavira <[email protected]>: >>> >>>> All, >>>> >>>> When conflict starts, it pretty much *always* starts with a >>>> misunderstanding. >>>> >>>> So what is interesting here is not so much the technical merit, or >>>> otherwise, within this discussion, but the routes by which >> misunderstanding >>>> occurred and how it led to conflict. >>>> >>>> What can we learn from this particular occasion? What could any of us >> have >>>> done differently in our communication? What incorrect assumptions did >> any >>>> of us make? (Usually, in conflict, both sides are making incorrect >>>> assumptions). >>>> >>>> If this does have the same flavour as previous conflicts, what can we >>>> learn about collective communication? What (probably small) adjustments >> can >>>> we make? >>>> >>>> Often one small adjustment is to watch out for one's own belief in your >>>> rightness. I'm certainly often guilty of this. It closes me down to what >>>> others have to say. How can we spend more time reading/listening before >> we >>>> respond? >>>> >>>> Just some thoughts. >>>> >>>> Upayavira >>>> >>>>> On Fri, 11 May 2018, at 1:14 PM, Carlos Rovira wrote: >>>>> Hi Harbs, >>>>> >>>>> really appreciate the new tone of your words. I think in that's the way >>>> to >>>>> reach consensus on things. I was feel attacked, and the final point was >>>>> Alex, in a position using words that should "make me understand the >> right >>>>> position". I sincerely know here nobody here is in the possession of >>>> truth, >>>>> but when people try to convince others in this way, I think there's no >>>>> dialog possible. >>>>> >>>>> I think all the problem is that before discussion Basic was just the >>>> basic >>>>> implementation or most "raw" way to do things. As you said, the basic >>>>> building blocks. After this discussion Basic sundenly becomes a piece >> in >>>>> the framework that we all must to use and can't avoid. I think that's >>>> wrong >>>>> by design. I think Core is what symbolizes that piece. and Basic is >> just >>>>> one more UI set, at least regarding on how is designed. Basic is not an >>>> UI >>>>> set library that has it's own CSS that Links lots of beads and styles >> to >>>>> the application that uses it. And Jewel is in itself a non dependent UI >>>> set >>>>> and is how I'm designing it with lots of hours invested in make it the >>>> most >>>>> simple, reusable solution that enforces PAYG, DRY and composition. >>>> There's >>>>> no point in make me embrace Basic for Jewel since there's no need to >> use >>>>> it. And that should be understood. I give lots of technical points as >> you >>>>> all requested, and hope all that previous emails will be sufficient for >>>> you >>>>> to reconsider the position of making all libraries in Royale obligated >> to >>>>> link Basic. I'll never would want Jewel make that, since I hope people >>>>> could get rid of useless dependencies and choose the pieces of code >> that >>>>> server their needs. >>>>> >>>>> About the Alex emails, although he wants to agree to the mantra, I >> think >>>> I >>>>> responded with sufficient valid points to expose that while I agree >>>> mostly >>>>> in the way he envisions royale. This concrete point of making Basic a >>>> Core >>>>> piece is not valid for me. >>>>> >>>>> So, I don't mind if finaly some pieces of Basic goes to Core, or if >> Basic >>>>> is splitter in two libraries. But the rest of the project should not >> link >>>>> obligatorily a library that enforces some CSS and beads if there's no >>>> need >>>>> of it. Maybe Core + some more part of Basic (lets's call BasicPrime), >> is >>>>> really the Core here, so for me if all libraries and applications must >>>> use >>>>> it, lets put all what's needed in Core. If you like more to split in >>>> Core + >>>>> BasicPrime, for me is ok as well although I think is the same as one >>>> Core, >>>>> and only will make things a bit more complex with two library core >>>> projects. >>>>> >>>>> And the end of this, and as you can see I think there's room to make >> more >>>>> things here. I only want one concrete thing and is to avoid the >>>> obligation >>>>> to link a library of a different UI Set that brings lots of things to a >>>>> Jewel App that should not be there due mainly to CSS and things that >>>> comes >>>>> with it. >>>>> >>>>> To resolve this, is far easy to move from the current point, that >> revert >>>> to >>>>> make this. And that can be done if we all work as a team. >>>>> >>>>> I'll be glad to help in all that I can, since I'm fully working all day >>>> on >>>>> this. But to do so we must to think that we all want things done in a >>>>> concrete way, and my point is that really we are not overlapping what >> we >>>>> need and all what all need have room in this project, since in the >>>> essence, >>>>> we agree in PAYG, composition and the overall structure. >>>>> >>>>> Hope this helps to calm things. Again, appreciate your tone and makes >> me >>>>> think all have solution here. Thanks >>>>> >>>>> >>>>> Carlos >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> 2018-05-11 13:13 GMT+02:00 Harbs <[email protected]>: >>>>> >>>>>> Hi Carlos, >>>>>> >>>>>> I just took a step back and re-read the thread. I’m not sure exactly >>>> where >>>>>> things went off the rails. The discussion seems to be mostly technical >>>> to >>>>>> me. I’m sorry if you feel attacked, and I can tell you that I did not >>>> mean >>>>>> anything like that. I definitely appreciate all the work you have been >>>>>> doing. >>>>>> >>>>>> When I mentioned that my app was broken I was just explaining my >>>>>> frustration. My broken app is not a reason in itself to revert things >>>> and >>>>>> like I’ve mentioned quite a few times already, I did not mean that I >>>> would >>>>>> revert commits without consensus. I’m sorry if it was taken that way. >>>> If a >>>>>> refactor is the right thing to do and others agree, I am fine to go >>>> along >>>>>> with it. I’m not trying to push my own agenda if it’s wrong. >>>>>> >>>>>> As hard as it might be to accept, I truly don’t understand the >>>> technical >>>>>> drive to do the refactor. If others do understand it, I would be >>>> willing to >>>>>> go along with it even if I don’t. >>>>>> >>>>>> However, I’m not seeing that there is a consensus that the refactor is >>>>>> correct. I might have missed some other discussion before the >>>> refactor, but >>>>>> it was not clear to me before the fact that a refactor was happening. >>>>>> >>>>>> No-one is trying to destroy others’ work and I don’t think there are >>>> any >>>>>> personal attacks going on here. We simply need to come to a consensus >>>> on >>>>>> whether the refactor is the right way to go or not. This should not be >>>> a >>>>>> personal disagreement at all. I think we all generally work well >>>> together. >>>>>> If you feel strongly that it’s the right thing to do, then please try >>>> to >>>>>> find the words to convince others of that. Alex asked some good >>>> targeted >>>>>> questions. That seems like the right place to figure this out. >>>>>> >>>>>> I hope we resolve this soon, >>>>>> Harbs >>>>>> >>>>>>> On May 11, 2018, at 12:53 PM, Carlos Rovira <[email protected] >>>>> >>>>>> wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> in writing this to summarize all the problems, far beyond code, that >>>> we >>>>>> are >>>>>>> living in the "Container Change" thread. >>>>>>> >>>>>>> We're repeating the same pattern with the same problems we had in >>>> Apache >>>>>>> FlexJS project. Now that we created this new project Apache Royale, I >>>>>>> though we'll be not living the same, but the problems are here. And >>>> are >>>>>>> exactly the same problems. The difference is that only a subset of >>>>>>> contributors are the same, so maybe the problems at that time wasn't >>>>>>> exactly as we thought? I must say that at that moment I was not part >>>> of >>>>>> the >>>>>>> discussions, so not part of that subset. You all can get your own >>>>>>> conclusions from this new discussion. >>>>>>> >>>>>>> For me the fact that a PMC member state that he's "going to revert" >>>>>>> something that is working only based on how this affects at its own >>>>>>> personal application code is simply not acceptable at all. This >>>> already >>>>>>> happen in FlexJS, and with the same person. This is not the project >>>> of >>>>>>> anyone here. Is an Apache OS project and for that reason we cann't >>>> make >>>>>> our >>>>>>> changes thinking in a single one application. >>>>>>> My changes are not motivated to match a concrete application, but to >>>>>> serve >>>>>>> the general purpose of this technology. >>>>>>> >>>>>>> In that thread, people asked me about "technical motivations". I >>>>>> expressed >>>>>>> various times a significant populated list of points based on the >>>> core >>>>>>> points that are part of our nature (PAYG, DRY, composition, and >>>> more...) >>>>>>> and even some significant improvements that we get after the >>>> refactor: >>>>>>> reduced size in *all* example applications that use Jewel about a >>>> 40%, >>>>>>> avoid collisions with other UI sets that do the same, and many others >>>>>> that >>>>>>> I don't want to repeat here. >>>>>>> >>>>>>> Then I asked for a list of the same "technical motivations" to have >>>> Basic >>>>>>> present in all applications made with Royale. And the only >>>> motivation was >>>>>>> not technical was: "since we did in this way before and we don't >>>> want to >>>>>>> change this". So completely philosophical. >>>>>>> "Why I must to link or depend from Basic? response: Since we did >>>> always >>>>>> in >>>>>>> the same way..." ¿¿?? >>>>>>> >>>>>>> The thread was asking me the same things although I was all the time >>>>>>> responding to the same in different ways to make people understand >>>> all >>>>>> the >>>>>>> implications, and provide my support to make changes and help with >>>> any >>>>>>> issue. But the response continues to be: "No. My application is >>>> broken >>>>>> and >>>>>>> I want to revert your changes" (a.k.a, my application is more >>>> important >>>>>>> that the Apache Royale project and I think I can dictate how we >>>> should >>>>>>> proceed) >>>>>>> >>>>>>> For me this is some kind of dictatorial way of doing things, and not >>>> the >>>>>>> apache way. >>>>>>> >>>>>>> This makes me change my way of doing things in this list though the >>>>>>> thread..., since people here is "dictating" certain things, I think, >>>> I >>>>>> have >>>>>>> the same rights than them, so my commit was done in the right form. >>>> Since >>>>>>> as the rest of members in this project, I created a branch, and made >>>> two >>>>>>> commits, and then merged. Could be this discussed more? Yes, but the >>>> same >>>>>>> as with any other commit here. I used to discuss previously, and I >>>> used >>>>>> to >>>>>>> ask for inputs, acceptance, and more (Something that I don't >>>> remember in >>>>>>> all committers) . This time, I'm so sure that the change was the >>>> right >>>>>> one, >>>>>>> that I committed in the same way you all do when you think the >>>> change is >>>>>> ok. >>>>>>> >>>>>>> Now that people is using dictatorial ways, I think I'm opposed to >>>> discuss >>>>>>> my commit. Or if we want to discuss it, I first would want to discuss >>>>>> many >>>>>>> others commits that I'm not conform, but I left in my philosophy of >>>> "live >>>>>>> and let die". I think when people dictates things the way to proceed >>>>>> should >>>>>>> be the same. >>>>>>> >>>>>>> I feel attacked, and don't know why. I think I already make merits in >>>>>> this >>>>>>> project so people could trust my work: >>>>>>> >>>>>>> * MDL: was a library I started and develop in a huge part with the >>>> help >>>>>> of >>>>>>> Piotr. And I started and finished until the end, while other UI sets >>>> are >>>>>>> still or incomplete or are only experiments >>>>>>> * AMF: I worked as well in this part to make sure we had something >>>> that >>>>>>> people on the list has expressed they need. >>>>>>> * JEWEL: I'm creating alone a complete UI set that looks polished to >>>> be >>>>>>> used in production. >>>>>>> * Compiler: I finaly are knowing how to do things there and I finaly >>>>>> fixed >>>>>>> many things specially on CSS. >>>>>>> * Maven: As well I'm more familiar and solved many problems in >>>> building, >>>>>>> some arise thank to this refactor. >>>>>>> * Website: I develop all the website alone >>>>>>> * Blog Examples: I'm creating one or two post to engage the community >>>>>>> * Social Networks: We have now Twitter, Facebook, Google+ and >>>> LinkedIn >>>>>>> working and moved continuously only by me, and getting a good >>>> traction. >>>>>>> >>>>>>> I'm working fully on this project from many months (8-12 hours day), >>>> and >>>>>>> what I get is a person that is frustrated since my change broke his >>>>>> app... >>>>>>> a co-mate working in his app ask about some changes (although I >>>> don't see >>>>>>> real align to one or another line, but assume that if asked he's in >>>> the >>>>>>> same boat that the first one), other people join to the discussion to >>>>>> then >>>>>>> apologize to me privately and personally, and finally other PMC >>>> members >>>>>>> only gave me a reason non technical that thing was "as is" from the >>>>>>> beginning. >>>>>>> >>>>>>> I'm all for communication, and I'll be spending all the time needed >>>> in >>>>>> this >>>>>>> point to go forward and fix whatever is not working. But the current >>>> way >>>>>> is >>>>>>> not the way to go. I can go back from now on and ask about how people >>>>>>> thinks about things I want to do. I usually do (The latest was about >>>>>>> spending facebook donation, how, when,...), but demand the same for >>>>>> others, >>>>>>> and end this kind of dictatorial ways of managing things, we are all >>>> in >>>>>> the >>>>>>> same boat, there's no leader here, there's no boss here, there's >>>> only an >>>>>>> Open Source project that at least I want to make it shine and we are >>>>>>> loosing our time with the noise generated by a single person and his >>>>>> broken >>>>>>> app, instead of joining the effort to make all working ok and that >>>> we all >>>>>>> get all the requirements we all want, we are trying to impose things >>>>>> while >>>>>>> my changes are done to get more freedom. I'm against that >>>> dictatorial way >>>>>>> of doing things. >>>>>>> >>>>>>> People that doesn't want how I'm designing Jewel, can simply not use >>>> it, >>>>>>> and can make it's own UI Set in parallel, stick with Basic or >>>> whatever >>>>>> they >>>>>>> want. As well I'm for "Live and Let die", I expect the same from the >>>>>> rest, >>>>>>> and only help when is required to help the project. I'm not forcing >>>>>>> anything in this project to make people need Jewel, while others >>>> want we >>>>>>> depend obligatorily from Basic and that's not needed.Having the >>>>>> possibility >>>>>>> to make people choose what they want and not force anyone to use what >>>>>> they >>>>>>> don't want (in this case Basic) is crucial. I don't plan to mess >>>> more in >>>>>>> Basic, since I want to avoid this situations >>>>>>> >>>>>>> So, I'll be one last time asking here to reconsidere how things are >>>>>>> managed, how things are asked, avoid unilateral actions that destroy >>>>>>> other's work. >>>>>>> >>>>>>> I propose to left the discussion to cold this weekend. Hope people >>>> return >>>>>>> on Monday with the motivations restored and want to continue forward, >>>>>> left >>>>>>> the discussion and we talked about how to fix whatever build is >>>> broken, >>>>>>> plan to release, do more work on social netiworks, publish new blog >>>>>>> content, follow working on Jewel, MXRoyale, and more. >>>>>>> >>>>>>> Let me know, what you prefer. >>>>>>> >>>>>>> Thanks >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Carlos Rovira >>>>>>> https://na01.safelinks.protection.outlook.com/?url= >> http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com% >> 7C68a39fc1a1ac4c6e7a7308d5b746cee4%7Cfa7b1b5a7b34438794aed2c178de >> cee1%7C0%7C0%7C636616437110115902&sdata=GBUHO%2BzEdYQ5ydYry1CSTUIBt% >> 2BR1c4AZtjpsemoZ9ns%3D&reserved=0 >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Carlos Rovira >>>>> https://na01.safelinks.protection.outlook.com/?url= >> http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com% >> 7C68a39fc1a1ac4c6e7a7308d5b746cee4%7Cfa7b1b5a7b34438794aed2c178de >> cee1%7C0%7C0%7C636616437110115902&sdata=GBUHO%2BzEdYQ5ydYry1CSTUIBt% >> 2BR1c4AZtjpsemoZ9ns%3D&reserved=0 >>>> >>> >>> >>> >>> -- >>> Carlos Rovira >>> https://na01.safelinks.protection.outlook.com/?url= >> http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com% >> 7C68a39fc1a1ac4c6e7a7308d5b746cee4%7Cfa7b1b5a7b34438794aed2c178de >> cee1%7C0%7C0%7C636616437110115902&sdata=GBUHO%2BzEdYQ5ydYry1CSTUIBt% >> 2BR1c4AZtjpsemoZ9ns%3D&reserved=0 >>> >>> >> >> > > > -- > Carlos Rovira > http://about.me/carlosrovira
