Hi Dave, thanks for your words!
I'll follow, your suggestion. But seems at least Alex and me have very clear their thoughts and I'm afraid that are diametrically opposed. Have a great week end too! :) Carlos 2018-05-11 20:25 GMT+02:00 Dave Fisher <[email protected]>: > 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 > > -- Carlos Rovira http://about.me/carlosrovira
