Hi Piotr,

ok, as we are still in preview site, not published, I think is better to
wait for the final link.
One thing is confusing me is that status link is more legit (
builds.apache.org) than the nightly links (apacheflexbuild.cloudapp.net)

I think in a final stage we should not have "apacheflexbuild" right?
But status seems ok to me at first sight

thanks

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>*
>



-- 
Carlos Rovira
http://about.me/carlosrovira

Reply via email to