I'm sorry! CARLOS I meant :) 2017-11-12 20:04 GMT+01:00 Piotr Zarzycki <piotrzarzyck...@gmail.com>:
> Another thing is: "Apache Royale Jenkings Job Status" - This status > showing the state of Maven build which is hosted on builds.apache.org. > Since we are using Alex's machine for producing ditribution package for > developers we should not have it this link on the website. > > Maven is able to build distribution package, but so far it's missing some > things and you can use that package only for code completion purposes in > your IDE either Moonshine or VSCode. If I find resources I hope I will fix > it and we can then linking to Maven build. > > Thanks Carslo for that website! :) > Piotr > > > 2017-11-12 18:42 GMT+01:00 Piotr Zarzycki <piotrzarzyck...@gmail.com>: > >> Hi Carlos, >> >> Here you go links to Royale. I see proper names. Royale [1] JS Only [2]. >> I did just quick look and when I came to the website I started to search >> this information that Nightly is not for production. After w while I have >> found this red rectangle. I think font size could be a bit bigger there. >> >> [1] http://apacheflexbuild.cloudapp.net:8080/job/royale-asjs >> /lastSuccessfulBuild/artifact/out/ >> [2] http://apacheflexbuild.cloudapp.net:8080/job/royale-asjs >> -jsonly/lastSuccessfulBuild/artifact/out/ >> >> Piotr >> >> >> >> 2017-11-12 18:30 GMT+01:00 Carlos Rovira <carlosrov...@apache.org>: >> >>> Hi, >>> >>> here's the download page for you to review. >>> >>> http://royale.codeoscopic.com/download/ >>> >>> Some things to mention: >>> >>> * As we already don't have release binaries, the first section could be >>> consider under construction >>> * For nightly builds I use the links posted by Alex in October. I think >>> those links are somewhat temporal since are labeled in "FlexJS" instead >>> of >>> "RoyaleJS" or something and he mentions the to rename in the future. >>> >>> You can check if links are the expected, or we need to put something >>> more. >>> >>> Take into account that the info is what I found navigating through the >>> mailing list and since I'm not a user of that links, although we will >>> need >>> to update as we get final names, they can be wrong links at this time. >>> >>> Hope you guys could let me know what is right and wrong >>> >>> Thanks >>> >>> Carlos >>> >>> >>> >>> >>> >>> 2017-11-11 11:35 GMT+01:00 Carlos Rovira <carlosrov...@apache.org>: >>> >>> > Hi Alex, >>> > >>> > as in lots of things in life I think we should get to some point in the >>> > middle. I think it would be bad if we try to make lots of components >>> in few >>> > time, since as you said, we don't know what things people will need >>> > nowadays. I like your point about "we don't need to mimic Flex 4.x", >>> for >>> > example, a cool Date component should work seamlessly in mobile and >>> > desktop, so better to create a royale one than try to get Flex 4 >>> > DateChooser and DateSpinner, since we have in flex both due to the way >>> Flex >>> > was evolving through the years. They worked great for the web and >>> desktop, >>> > but suddenly a new mobile world emerge and they must respect the old >>> way to >>> > do things. >>> > >>> > In the other hand, I think it would be very bad for us to left things >>> > completely to users demand. We know right now that some components are >>> > needed and we can propose others as well. >>> > >>> > I think I'll better create a new thread since I think this one was more >>> > about releases and nightly builds so we can stay on focus >>> > >>> > >>> > Thanks >>> > >>> > >>> > >>> > >>> > >>> > >>> > 2017-11-11 8:04 GMT+01:00 Alex Harui <aha...@adobe.com.invalid>: >>> > >>> >> 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%7C4ddfd5d3bb8e44f9b4c508d5287 >>> >> 3f24b%7Cfa7b1b5 >>> >> >a7b34438794aed2c178decee1%7C0%7C0%7C636459400811686261&sdat >>> >> a=AONFxld%2FTJz >>> >> >zDM%2Frjf0g6L8PfwqlpJHkF9RVZII1TWo%3D&reserved=0 >>> >> >>> >> >>> > >>> > >>> > -- >>> > Carlos Rovira >>> > http://about.me/carlosrovira >>> > >>> > >>> >>> >>> -- >>> Carlos Rovira >>> http://about.me/carlosrovira >>> >> >> >> >> -- >> >> Piotr Zarzycki >> >> Patreon: *https://www.patreon.com/piotrzarzycki >> <https://www.patreon.com/piotrzarzycki>* >> > > > > -- > > Piotr Zarzycki > > Patreon: *https://www.patreon.com/piotrzarzycki > <https://www.patreon.com/piotrzarzycki>* > -- Piotr Zarzycki Patreon: *https://www.patreon.com/piotrzarzycki <https://www.patreon.com/piotrzarzycki>*
