Hi Justin, I'm not disagreeing about using JIRA more. But I'm not sure that mandating that JIRA be a complete replica of development activity is a good idea. But I'd like to hear from others. Maybe the rest of the community does want to mandate JIRA. To me, JIRA is a great "to-do" tracker, but we want to encourage discussion on the dev@ list and I would not want to be required to have to duplicate every discussion in JIRA.
And just like others are asking questions on the dev@ list, I encourage your team to do so as well, and do so sooner than you might when working with those corporate-driven projects that purposefully keep you on the outside. I assume your developers discuss things over email and in person and don't have to interact entirely through JIRA. All I'm saying is that your team is welcome to do the same on dev@. Don't spend too much time trying to verify findings or find workarounds, just ask. Pan's problem wasn't in the compiler, it was in the ActionScript code. I think your folks are capable of at least debugging into the framework and pinpointing the issue. From there you can file a JIRA and just wait or try to find a workaround, or you can start a discussion on dev@ and if it turns out there is work that needs to be done, file a JIRA and propose a fix if you have one. And maybe learn from that discussion so you can more efficiently diagnose the next problem. You can't easily do that with the corporate-driven projects, but you can do that at Apache. And that gives you more control over what bugs get fixed and when. Because Apache projects are volunteer-driven, it is hard to put in place any sort of roadmap. I understand that creates some unpredictability, but I think that is best when working with volunteers. They can't commit to when and how much time they have to contribute so when they show up, those of us with more time have to constantly re-evaluate what we are doing and shift gears. It would have been bad for the community if I told Carlos that I'd committed to a particular list of tasks and couldn't help him get his Material Design library up and running. That library may prove to be more important than what I was working on at the time. So again, I encourage all of us to use JIRA more, but I also encourage your team to act more like part of our team. -Alex From: "Justin M. Hill" <jus...@prominic.net<mailto:jus...@prominic.net>> Date: Friday, November 4, 2016 at 10:13 AM To: Alex Harui <aha...@adobe.com<mailto:aha...@adobe.com>>, "dev@flex.apache.org<mailto:dev@flex.apache.org>" <dev@flex.apache.org<mailto:dev@flex.apache.org>> Cc: "Dhwani K. Shah" <dhw...@prominic.net<mailto:dhw...@prominic.net>>, "Joel C. Anderson" <j...@prominic.net<mailto:j...@prominic.net>>, "Kinjal J. Patel" <kin...@prominic.net<mailto:kin...@prominic.net>>, Pan Li <pa...@prominic.net<mailto:pa...@prominic.net>>, Santanu Karar <sant...@prominic.net<mailto:sant...@prominic.net>>, "Walker L. Dalton" <wal...@prominic.net<mailto:wal...@prominic.net>> Subject: Re: FlexJS -- we really need to get bugs into JIRA Hi Alex, I understand what you are saying about Apache having a unique approach, but on the other hand countless software development projects have been improved by better tracking. When it is possible to associate a bug's fixes with changes in the source code, everyone following the project has clarity. This helps in the long run to improve the community's understanding of the code. Our team is doing everything we can to help, and our focus is on the IDE. This has certainly presented a lot of challenges and kept us busy. We have a massive list in our own JIRA of bugs and enhancements for Moonshine. So everyone here can see where things are going. I have encouraged the rest of the team here to contribute to FlexJS as well as we can, but aside from the TabComponent Dhwani and Kinjal worked on I am not sure we have the skill set to be modifying the compiler. I continue to think FlexJS would benefit from a central, organized repository with a written path of objectives beyond what is in the mailing list. I understand this is a time consuming item and takes away time from coding. I think there is great value in this time investment and will help others see what is being done over time and how they can help tackle issues. I hope we can shift as a community to the JIRA model of bug tracking for FlexJS. Thank you, Justin Hill My Apache Flex community contribution is working on the open source Moonshine-IDE.com for FlexJS. [Inactive hide details for Alex Harui ---11/04/2016 11:51:16 AM---Hi Justin, I think we are using JIRA more these days, but IMO,]Alex Harui ---11/04/2016 11:51:16 AM---Hi Justin, I think we are using JIRA more these days, but IMO, it still isn't worth documenting ever From: Alex Harui <aha...@adobe.com<mailto:aha...@adobe.com>> To: "Justin M. Hill" <jus...@prominic.net<mailto:jus...@prominic.net>>, "dev@flex.apache.org<mailto:dev@flex.apache.org>" <dev@flex.apache.org<mailto:dev@flex.apache.org>> Cc: Pan Li <pa...@prominic.net<mailto:pa...@prominic.net>>, "Dhwani K. Shah" <dhw...@prominic.net<mailto:dhw...@prominic.net>>, Santanu Karar <sant...@prominic.net<mailto:sant...@prominic.net>>, "Kinjal J. Patel" <kin...@prominic.net<mailto:kin...@prominic.net>>, "Walker L. Dalton" <wal...@prominic.net<mailto:wal...@prominic.net>>, "Joel C. Anderson" <j...@prominic.net<mailto:j...@prominic.net>> Date: 11/04/2016 11:51 AM Subject: Re: FlexJS -- we really need to get bugs into JIRA ________________________________ Hi Justin, I think we are using JIRA more these days, but IMO, it still isn't worth documenting every change in JIRA. Apache projects are supposed to feel more like potlucks than corporate efforts, and I don't want some volunteer with only an few minutes of time to decide not to contribute a null check because they have to fill out a JIRA issue before committing a change. so there is always a chance something will be missed in JIRA. Searching the dev@ and commits@ lists and trying the nightly build should probably become a standard practice before reporting a bug. Anybody can have a JIRA account, and yes, I encourage everyone to file bugs, but I know not everyone will. Also realize that your list of other frameworks are all corporate controlled which is why you felt compelled to list the corporation's name with the framework's name. The Apache model is different. At Apache, folks from all over the world can be committers and thus don't have to use JIRA in order to get something fixed, they can just do it. In fact, I would rather your team propose fixes instead of trying to workaround bugs in Flex or FlexJS code. Then they are more likely to earn committer rights and can just make a fix. IMO, that will be way more efficient than having to file JIRA issues and wait for someone else to fix it. If your team can think and act like they are part of our team, then I think we will make the most progress. The dev@ list is our common area. The other folks writing code for FlexJS often just ask on dev@ "Hey, I'm having a problem with this, is anybody else?" I'll bet Pan asked that internally to the rest of your team, but if Pan asked that right away on dev@ then we would all have saved time. It is a different way of thinking, but that's the cool thing about Apache. You can have more direct involvement than you can with other corporate-driven projects. -Alex From: "Justin M. Hill" <jus...@prominic.net<mailto:jus...@prominic.net>> Date: Friday, November 4, 2016 at 9:16 AM To: Alex Harui <aha...@adobe.com<mailto:aha...@adobe.com>>, "dev@flex.apache.org<mailto:dev@flex.apache.org>" <dev@flex.apache.org<mailto:dev@flex.apache.org>> Cc: Pan Li <pa...@prominic.net<mailto:pa...@prominic.net>>, "Dhwani K. Shah" <dhw...@prominic.net<mailto:dhw...@prominic.net>>, Santanu Karar <sant...@prominic.net<mailto:sant...@prominic.net>>, "Kinjal J. Patel" <kin...@prominic.net<mailto:kin...@prominic.net>>, "Walker L. Dalton" <wal...@prominic.net<mailto:wal...@prominic.net>>, "Joel C. Anderson" <j...@prominic.net<mailto:j...@prominic.net>> Subject: FlexJS -- we really need to get bugs into JIRA Hi Alex, Everyone here at Prominic would like to see JIRA being used more for Flex development to track issues. We are very glad to hear that the nightly 0.8.0 build solved the issue Pan reported. This has apparently happened before -- where we have spent > 1 day determining something was a bug, and then another couple of days to re-write code to work around the bug. This time would have been better spent had we known the bug was already on a list and being worked out. As a community, we are up against a wide variety of frameworks. Known bugs should be in bug database. I am sure Google's AngularJS, Microsoft's Xamarin, Facebook's ReactJS or any other mature cross-platform UI SDK are tracking bugs, and FlexJS needs to be doing the same. The overall Apache Flex JIRA appears to be here: https://issues.apache.org/jira/browse/FLEX/?selectedTab=com.atlassian.jira.jira-projects-plugin:summary-panel and the FlexJS 0.8 specified project is here: https://issues.apache.org/jira/browse/FLEX/fixforversion/12338251/?selectedTab=com.atlassian.jira.jira-projects-plugin:version-issues-panel Are we not looking in the right spot, or is the community just not properly documenting bugs? Can Prominic staff get logins to JIRA to help report these? Thank you, Justin Hill My Apache Flex community contribution is working on the open source Moonshine-IDE.com for FlexJS. ----- Forwarded by Justin M. Hill/A55555/PNI on 11/04/2016 12:05 AM ----- To: "dev@flex.apache.org<mailto:dev@flex.apache.org>" <dev@flex.apache.org<mailto:dev@flex.apache.org>> Date: 11/03/2016 11:33 PM Subject: Re: [FlexJS] Container.numElements is not working ________________________________ Thanks. Please try the nightly 0.8.0 build. It should be fixed already. -Alex > > >platform: Mac OS 10.4; FlexJS 0.7 > >numElements of the UI element Container doesn't work, it can be reproduced >by this code snippet: > ><js:Container id="holder" width="100%" height="100%" > > <js:beads> > <js:VerticalLayout/> > </js:beads> > <js:Label text="fooo"/> > <js:Label text="wooo"/> > <js:Label id="debug" text="tooverride"/> > <js:TextButton text="GO" click="debug.text = String >(holder.numElements)" /> ></js:Container> > >Run it in FlexJS0.7 in javascript or awf mode, it will show "1", but >expected value is 4. > >Similar code in Flex works as expected: > > <mx:Panel id="holder" title="Panel" status="Active" > width="75%" height="75%"> > <s:Label text="fooo"/> > <s:Label text="wooo"/> > <s:Label id="debug" text="tooverride"/> > <s:Button label="GO" click="debug.text = String >(holder.numElements)" /> > </mx:Panel> > >I also noted the api list of FlexJS's Container is much shorter than >Flex's >Container, does this mean Container of FlexJS is not fully finished? > > >Thanks >Pan LI > > >My Apache Flex community contribution is working on the open source >Moonshine-IDE.com for FlexJS.
