Hi Harbs, El mié., 5 dic. 2018 a las 18:42, Harbs (<harbs.li...@gmail.com>) escribió:
> Just to examine these steps and try to communicate how I would have > handled them: > > When I run into a similar problem while using “bleeding edge” code, my > first step is to write the problem to the list ASAP. I’ll spend the minimum > time necessary to isolate the problem and then describe the problem as > concisely as possible. Discussion usually helps flush out what the problem > is and helps find a course of action. > > If I am stuck and must continue working, I will do one of two things: > > 1. Locally I will revert to previous code if I can. Usually with compiler > issues, this is possible. > 2. Create a temporary branch for my own use. If the change is useful to > illustrate the problem (or it needs to be shared with others), I will push > the branch to the remote. > > I'm with you in the global way to proceed. > As you mentioned, your commit was likely to be reverted. That makes it a > prime candidate for a temporary branch. Although I’m not sure why you > couldn’t just revert to prior to Alex’s change locally to keep on working. > > I don’t think there was anything wrong with Alex committing his code to > develop. We discussed the problem he was trying to solve and the change > fixes it as intended. I don’t think anyone was aware that you were missing > MXRoyale and Jewel. (I definitely was not.) > If the commit doesn't make any regression, that will be ok for all of us. The problem as you said is maybe nobody was aware about someone using Jewel+MXRoyale. That is a legit way of use Apache Royale and should not be anything strange. So If I were Alex and suppose I make a change, directly in develop, and found someone found a regression, my first way to proceed is to put my muscle to try to help in something that was caused by my changes, not say "is not my problem, do it yourself or pay someone to do it", and start a long thread of emails. If that's the way to do this, I'm with Dave and we should move this issue to a branch and work there to solve the regression. So we don't bother the rest of developments that are confirmed and working. IOW, changes that we detect a problem should be done in a branch, no make the rest of us move to a branch. The use in all projects I now is this, and seems we are trying to do the opposite. > > I can’t imagine why it should not be possible to include the MXRoyale swc > in a Jewel project (or vice versa). It should just be a matter of figuring > out the correct configuration. Like Josh, I’d be interested in the details > to understand the problem better. > > Right, I don't know if is a bug in Royale, in config or in VSCode extension. I spend several hours on my own trying different configs (that's what we supposed it should fix the problem), but this comes in a bad time for me since I'm working hard to get our App ready and our client happy. In other timeframe I'll be already put some hours on this. But in the other hand the way Alex is managing this makes me feel not happy and asking me that I must invest hours or pay persons for something I did't ask for makes me ask myself if that's the way to operate here or if this is the way to go in an apache community. I think I could never ask others to work on something I did and caused some general issue or recommend pay others to solve things to complete the tasks I'm working on, does not seems to me the Apache way and I don't see my self with the power/status to say others to do that...I'm just another contributor to this project. > My $0.02, > Harbs > > > On Dec 1, 2018, at 9:29 PM, Carlos Rovira <carlosrov...@apache.org> > wrote: > > > > 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" > -- Carlos Rovira http://about.me/carlosrovira
