Well, I would love to be wrong about "few years", but I know I wouldn't bet any money on knowing what components and features our users who are migrating from Flex are going to need. And I would hope we don't have to say to any users "well, we don't have that component/feature so too bad", unless it is a really extensive and expensive component that we don't have the committer-power to reproduce. Maybe we do have the ability to gather that list of components/features up front, but I am expecting that we are going to have to be demand-driven. Whoever signs up to migrate to Royale will have my priority just like Harbs and Yishay did. I did not ask them to commit up front to what they needed, they started migrating and asked for stuff and we made it happen. I expect it to be like that for at least a few years, and we need to be able to make releases quickly in order to respond to those users.
I'm hopeful that as we gain users, we will also have more automated tests and that's how we are going to try to prevent breaking people's apps, but I think we will be spending at least a few years bringing new components and features to Royale and need to get that stuff out to users as quickly as possible. If you think about the number of person-hours invested in the writing and testing and documenting of Apache Flex and its third party components, and compare that to the time Peter and I have spent on Royale (subtract out what we've spent on Flex and non-FlexJS work) plus Harbs and Yishay (subtract out the time they spent on their actual app) and others like Om, Erik, Carlos and Piotr, it looks to me that there is still plenty of work to be done, and the only way to decide what order to do things is to do what users ask us for. I know you want a clear list of controls/components for a theme, but I don't know how we will decide other than, say, taking the ones actually used by Harbs and adding any other component wanted by the next folks that sign up for migration. My philosophy is to not set expectations too high (that Royale will be like Flex 4.x) and failing to meet those expectations. If we make a lot of noise soon, what kinds of people will that bring, and what will make them stay? If we can attract more pioneers like our current committers who are willing to help blaze the trail, great, let's go get them. If it is going to bring in folks who are expecting Royale to be like Flex, I'm not sure we are there yet. I think this latter group is going to want to know about success stories from other people, so IMO, the most important thing is that we need to make a few more users successful in their migration. But those next users are going to have to be willing to put up with bugs and missing features, so we need to set their expectations appropriately. My 2 cents, -Alex On 11/10/17, 11:47 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira" <carlos.rov...@gmail.com on behalf of carlosrov...@apache.org> wrote: >Hi, > >I agree with this, but want to expose some thoughts that I consider >important: > >I think we must to cut a release as we get in the same similar stable >state >as we had in FlexJS (0.8.0), and call it 0.8.0, since this is only a >transition release to get in our new house, but we still have some missing >key pieces to get 0.9.0 and 1.0 > >I suppose a Alex talks about "some years" but I don't think so. If we do >0.9 and 1.0 in the right way, I expect to make huge noise on the internet >talking about Apache Royale and making lots of people put an eye on us. >This must be at proper time to get people reaching to us not leave easily >and take us seriously as a real alternative. > >How many time to get this? I hope more soon than later. Maybe 1T 2018? 2T? >People coming at that time will start to use Royale and we will need some >coherence all around. > >That's crucial and that will make us not easy to make certain changes that >could make user developments not valid. > >So, for example, We still does not have a clear list of starter UI >components and controls. I think we will need to discuss that and work for >it so people could rely on some quality components (I think I will create >a >thread about this concrete part since I think is crucial for us). We will >need to have certain parts of Royale very robust and defined so people >could come and expect and easy relation with that parts and avoid to left >because they think we "many things" but as well "many of that things are >not finished" in a quality level similar to the quality level reached on >apache flex. > >So, going back. We need to cut a release as soon as we can to get a valid >starter point, we need to release the new website with quality content and >what we could have soon (if we have royale on NPM, that's good!, and so >on....), we can put a download page with releases and talk about ways for >people to get nightly builds, but we must think in the people that will >come to us and what they expect to see; > >For me: something clear, as easy as possible info in website, an sdk with >proven valid ways to make apps and a concrete set of UI controls and >components that works really well to start building the same day they know >about Apache Royale. > > > > >2017-11-10 20:12 GMT+01:00 Dave Fisher <dave2w...@comcast.net>: > >> Hi - >> >> I agree it is intent and trust. A couple of incidents in the long >>history >> of POI. >> >> (1) we discovered a GPL file that had been in the source tree for a >>couple >> of releases and removed it. >> >> (2) we had a complaint from the copyright holder that a test file >>belonged >> to him. It had been there for many years. We removed it from the next >> release. >> >> Anyone concerned with nit picking this should be watching every commit. >>In >> the Incubator a mentor will bring it up then and most often say next >>time. >> Here in a project we deal as they come and it should be on the commit. >> >> If someone brings in a significant amount of code then a SGA may be >>needed >> along with IP Clearance in the Incubator. >> >> Regards, >> Dave >> >> Sent from my iPhone >> >> > On Nov 10, 2017, at 11:02 AM, Alex Harui <aha...@adobe.com.INVALID> >> wrote: >> > >> > Hi Dave, >> > >> > It would help to make license problems rare if we also do something >>else >> > Roy has mentioned recently that has to do with trust and intent. If >>you >> > dig hard enough, or take an "untrusting" philosophy that if something >> > isn't perfectly documented that someone is going to use that >>imperfection >> > against you or the foundation, you can continue to find small >>licensing >> > issues, especially in the third party artifacts we consume. >> > >> > Roy basically said that folks want us to use the stuff the make >>available >> > on open source sites otherwise they wouldn't have put it there. They >> > might have slightly different rules about sharing it and >>modifications to >> > it, but the intent is to share it. >> > >> > So let me add to "better and not illegal" with "trust". >> > >> > Thanks, >> > -Alex >> > >> >> On 11/10/17, 10:47 AM, "Dave Fisher" <dave2w...@comcast.net> wrote: >> >> >> >> Hi - >> >> >> >> For source code we can point to github from the website. >> >> >> >> For nightly builds we can let people know about it on dev@ but should >> not >> >> link to it from the website. We can explain on the website or wiki >>that >> >> we are doing nightly builds and that they can find out from the dev@ >> list. >> >> >> >> At this point it should be rare to have a license problem in the >> >> repository because we all should know the rules or how to ask on dev@ >> or >> >> private@ first. >> >> >> >> Clear? >> >> >> >> Regards, >> >> Dave >> >> >> >> >> >> >> >> Sent from my iPhone >> >> >> >>> On Nov 10, 2017, at 10:36 AM, Alex Harui <aha...@adobe.com.INVALID> >> >>> wrote: >> >>> >> >>> Forking this specific issue about nightly builds... >> >>> >> >>> AIUI, this issue about nightly builds has arisen before with other >> >>> projects. I'd have to go through board@/member@ archives but I >>think >> >>> some >> >>> projects have found some pretty clever solutions to linking to >>nightly >> >>> builds. >> >>> >> >>> That said, one of the benefits of creating a Royale project separate >> >>> from >> >>> Flex is that there should not be any 'competition' in the release >> queue. >> >>> For example, the Flex project is currently trying to get two >>releases >> >>> out, >> >>> and if some other Flex member wanted to rush out a BlazeDS release, >> >>> they'd >> >>> probably have to wait. >> >>> >> >>> Royale has 3 main repos, and under FlexJS/Falcon, we created 2 sets >>of >> >>> release artifacts. Royale might still have 2 sets of release >>artifacts >> >>> ( >> >> > > >-- >Carlos Rovira >https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2 >Fcarlosrovira&data=02%7C01%7C%7C4ddfd5d3bb8e44f9b4c508d52873f24b%7Cfa7b1b5 >a7b34438794aed2c178decee1%7C0%7C0%7C636459400811686261&sdata=AONFxld%2FTJz >zDM%2Frjf0g6L8PfwqlpJHkF9RVZII1TWo%3D&reserved=0
