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
