Hi Alex, you continue talking of this in a way like like if the change you did is right and my fix is not. But don't see you in a point to put your commit in question. I can say the same as you describe in your email, but applied to your changes. Far beyond this concrete issue, I think we have a problem if you consider that you can commit a change that breaks current repo (don't need to be a build break, but other's like IDEs break), and when others fix the failing problem you state that others changes are really the problem. I think we're going in circles.
Always I make a change I'm prepared to others critics and as well I don't have problems in listen and revert my work or update when others have explained things and I see my errors. You see me do this taking into account your advices many times. So you can ensure I consider myself fallible. But you way is always state you're right, and does not have a problem with your commits. But I'm having. And not's a particular case. Is a case with Jewel, that has exactly the same importance that the rest of Royale (to avoid you refer to my case, as something that fails in some personal code or config in my own) This days are difficult to me since I'm fixing things in our current real world Royale App, so I still couldn't get to the problem in that branch. I think as well is important for the Apache Royale, this real project gets success, since that will mean one more success for Apache Royale getting a new App that works and goes to production. So I think at least this days that's priority I had to choose. About the problem, you said you asked some times in this thread, and I think I responded some times in this thread. Here's another try If you want to check the problem yourself, until I can get enough time do my own tries: 1.- grab VSCode and AS3&MXML extension 2.- build SDK in the branch where I reverted my commit and point VSCode to that SDK 3.- point a project like for example the MX RO test with Jewel example (so you have a project that uses Jewel and MXRoyale) Results: you should see the problems in VSCode maybe you can start from the current version to see that with an SDK generated from current branch problems are 0 and going to the branch with your changes, VSCode goes crazy. I think from now on we can stop to say you don't have enough data to reproduce the problem right? I think the problem could be that you don't use IDEs, but IMHO you should setup VSCode or Moonlight (that since uses the same core, should shows the same problem). You must have IDEs in mind, since we, are all in real projects using real tools for the work, so you can be agnostic of that reality, and if something breaks IDEs, the solutions we do must ensure IDEs continue to work. Thanks Carlos El mié., 5 dic. 2018 a las 0:13, Alex Harui (<aha...@adobe.com.invalid>) escribió: > When you are writing code for your app, you may or may not care about code > re-usability. When writing code for a framework, you must always care > about reusability. Thus, every change must be explainable. It isn't good > enough to make a change because it was the only way you can get something > to work. > > In this case, the change was to the list of default SWCs. It should be > possible to override all of those settings for your needs. I have offered > to help and asked for useful data on at least four posts on this thread. > So far, I don't have anything to work with. I'm trying to help, but it is > not a good use of my time to guess what the problem test case is. > > We must use sound engineering principles in creating a framework because > we want lots of folks to rely on it. I was amazed when Adobe shipped the > first generation of AS2 components with Flash MX that some folks spent > hours reading the code. We would want folks to do the same for Royale and > our code must make sense. Before changing someone else's code, you should > be able to explain why the code you are changing is flawed and why your > change is better. We have a commits history so you can go back and see > changes to help determine why things were changed. If you can't explain > your changes, don't push it. > > If something is a mystery, create a simple test case and add complexity > until it fails, or subset your complex test case until it stops failing. > Also consider whether the builds are working and whether anyone else is > complaining about related issues. Committers should be able to build from > sources, so rollback if you are in a hurry, but don't push a change if it > is just a guess. > > My 2 cents, > -Alex > > On 12/1/18, 11:30 AM, "Carlos Rovira" <carlosrov...@apache.org> wrote: > > Hi Alex, I don't think that's what happen. > > My version (always considering that there's my version, your version > and > the truth): > > 1.- You make a commit that introduced IDEs break > 2.- I spend Saturday morning trying to find a way to fix that > 3.- Instead of revert your commit I make a change of the thing causing > the > problem with the comment "to be reverted as we find the solution" > 4.- You was upset since you consider it a revert, and I asked you to > find a > way a solution so we all can live in peace and armony > 5.- You said me that I must to do it myself or pay someone to do it, > and > that Alina and others have priority over my needs > 6.- Dave told us that we should work on branches, since nobody is a > special > case here. > > We are on that point where we have a branch with a first commit that > is my > commit reverted, in order to find the solution. > > Since Royale has different sets no one is more important than other. > Basic, > Jewel, and not Mx/Spark must coexist, and should work in conjunction. > I'm using Jewel and MX for RPC part and some other classes (i.e. > CurrencyFormatter, and maybe others). The changes in config files make > IDEs > goes crazy. > So I can have a "jewel-config-template.xml", that has jewel, mx,...and > other libs needed, no problem on that, but when I tried to create > that, I > couldn't get it work. > That's point 2 in my list. For that reason maybe there's a bug and that > could be done, if that's the case, I think is Alex responsibility to > fix > that to leverage his change, > and not make me depend on my time or money to contract other people to > do > that. IOW, if we make a change that break something, and others > complains, > don't see > a point to make a battle for something like that. I think is more easy > to > work on fix that instead of invest time in a large thread and emails. > > Since this Friday I release our real work Apache Royale app first > iteration, I plan to work on that this week end, but finaly I must fix > things on our release for Monday, so I can work on that on this on > Monday > or Tuesday. > > > > > El jue., 29 nov. 2018 a las 10:40, Alex Harui > (<aha...@adobe.com.invalid>) > escribió: > > > As discussed I changed royale-config.xml to list all of our SWCs > except > > for MXRoyale and SparkRoyale, and changed flex-config.xml to use all > SWCs > > and have different default classes such as mx.events.MouseEvent > instead of > > org.apache.royale.events.MouseEvent. I think Carlos has the only > project > > using MXRoyale and Jewel and maybe some Basic so neither config is > set up > > exactly for his needs. Since all configuration is theoretically > > overridable as compiler options, he should have been able to get > going by > > specifying what SWCs he wants to use. > > > > He said he wasn't able to do that, so he committed a change that > went back > > to using a wildcard in royale-config.xml and thus pull in all SWCs > and > > re-introduce the problem. That doesn't make any technical sense to > me and > > brought back the CSS problem that was affecting folks like you. So > I asked > > him to revert his wildcard change and so far, he hasn't and instead > he > > started in on how I am seeking special treatment. > > > > -Alex > > > > On 11/28/18, 7:19 PM, "Harbs" <harbs.li...@gmail.com> wrote: > > > > I’m still not following. > > > > What did you change and what was the issue that Carlos hit? Am I > > correct that you were fixing the problem that MXRoyale was > overriding the > > Basic CSS? > > > > What exactly was the fix and why was it causing problems? > > > > > On Nov 28, 2018, at 5:21 PM, Alex Harui > <aha...@adobe.com.INVALID> > > wrote: > > > > > > Carlos reverted a commit I made without technical > justification and > > refuses to put back my changes when I asked, instead saying I was > acting > > like I should have special treatment. Apparently, Carlos couldn't > compile > > his app even though all of our examples build just fine. I've > tried to > > help, but cannot get solid data from Carlos. > > > > > > Somehow Dave Fisher thinks is ok for Carlos to act like that. > I > > think it sets a dangerous precedent to have committers revert other > > people's changes without technical justification, and also a bad > precedent > > to allow people to basically call people names when they disagree > about > > something. > > > > > > -Alex > > > > > > On 11/27/18, 4:52 PM, "Harbs" <harbs.li...@gmail.com> wrote: > > > > > > I have not been following the list very well the last week > plus. > > (I’ve been busy with some personal things.) > > > > > > I’m not following the issues here. What was changed, and > what’s > > the issue here? > > > > > > > > > > > > > -- > Carlos Rovira > > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C3184e1049ffa40fef9d108d657c36bc1%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636792894197456300&sdata=Sv5rPuwkJD0uDeRqjWFs27m9AHtJIBU9G%2FdM2iUwqro%3D&reserved=0 > > > -- Carlos Rovira http://about.me/carlosrovira
