Release Philosophy (was Re: [Website] Getting content ready to publish)

[Alex Harui <ah...@adobe.com.INVALID>]

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
(compiler, framework), or we could have 3 (one per repo: compiler,
typedefs, framework), or we could have 1 by bundling the 3 repos together.
 And whatever we choose now, we can change later, since some day there
will probably be a Tour de Royale or something like that.  Also, I have
made changes to Royale release packaging so that they should not be
dependent on an Installer release.  IOW, we have hopefully simplified our
releases (assuming folks are ok with the new ways to get SWF-related code).

The main Apache philosophy, AIUI, is simply that the foundation cannot be
telling the general public to download source that has not been vetted by
the Foundation (actually a PMC) as being entirely open source under
licenses compatible with ALv2.  Yes, there are exceptions for Cat B and
Cat X with proper handling, but that's the primary principle:  the general
public must only be consuming things we've reviewed and approved.  A
nightly build simply hasn't undergone that level of review.
 
Meanwhile, there appears to be distinctions at Apache about user-facing
and developer-facing "channels".  For sure, there is a dev@ and users@
mailing list, and there appears to be a notion of user-facing vs
developer-facing web sites or pages.  I haven't found a definitive
description of the latter, though.

In theory, folks who are reading dev@ have their "developer" hat on, and
so we can freely discuss nightly builds and where to get them on dev@.
AIUI, we can even tell an individual or group on users@ to grab a nightly
and see if it fixes a bug they've been experiencing or try a new feature
as long as we use the right words that the nightly is not a release for
the general public.

I'm not sure how to do the same on a web site.  AIUI, the main page at
royale.a.o is supposed to be a combination of user-facing and
developer-facing content.  It must instruct the general public where to
get releases, and it must also instruct newcomers as to where to get the
source code and participate.

But to tie all the above to the subject title, I want to mention something
Roy told me recently.  Roy said that for many projects, the criteria for
voting on a release is "better than the last release" and "not illegal".
And "not illegal" truly means breaking a law, not whether the release is
perfectly compliant with some Apache policy.  Apache Policy does not
always support compliance with some law.  Much of it is for consistency
and convenience.

For those of you who have participated in Apache Flex releases, the
philosophy there was quite different.  There was lots of nitpicking done
at the last phases of the release process.  This made some sense for
Apache Flex as each release was targeted at 100's if not 1000's of
existing Flex customers that may have had mission critical applications
relying on certain code-paths.  However, for Royale, at least for the next
few years, I think we should adopt the "better and not illegal"
philosophy.  I think that philosophy, combined with fewer release
artifacts, should allow us to release way more often than we used to.  And
that will reduce the importance of linking to nightly builds off our web
pages.  Nobody should really need to look at our web pages for links to
the nightly builds because they should be following the dev@ list or we
will be telling someone on users@ to try some nightly and giving them a
link in the email.  IOW, the links to the nightly should just keep coming
up in email conversation, and as long as we are careful on users@, we
should be fine.

I think I am done with renaming references to Flex in the framework.  We
could cut a release now if we want to, especially with a "better and not
illegal" philosophy.  I am choosing to wait on the release in order to
finish a major refactoring of the compiler because I saw some folks
struggle to get the repos to build and because the refactoring is needed
to remove the last batch of Flex references from the compiler.  The
refactoring is intended to make building from the repos much simpler and
leave a better first impression for those who try it, so I thought that we
should wait to make "first release" noise until we have smoothed that out,
but I'm fine if we want to ship what we have now.  This refactoring could
be at least another week or two of work.  Cutting a release with this new
philosophy should be much less than that although I suspect folks may have
feedback on the new packaging.

Thoughts?
-Alex

On 11/10/17, 3:24 AM, "Harbs" <ha...@gmail.com> wrote:

>We’re not tied. It just needs to be on a different page to avoid users
>downloading nightly versions by mistake.
>
>There needs to be two download pages:
>
>1. For “normal” users who only want to use stable releases.
>2. Framework developers and users who want to use the latest.
>
>Right now, we don’t have content for #1.
>
>Harbs
>
>> On Nov 10, 2017, at 12:31 PM, Carlos Rovira <ca...@apache.org>
>>wrote:
>> 
>> Hi Piotr, Justin,
>> 
>> as Justin, comments, I think we are tied until we get our first release.
>> It really doesn't matter to me since "downloads" page is something
>> currently not widely used is project like us.
>> As always, I like to refer to competence, and they use to point to NPM
>>or
>> Github and not post releases.
>> We can do it, but for me this is to conform with old habits. We should
>> expect that "young devs" will go directly to NPM
>> to get Apache Royale ;)
>> 
>> 
>> 2017-11-10 0:30 GMT+01:00 Justin Mclean <ju...@classsoftware.com>:
>> 
>>> Hi,
>>> 
>>>> Great job. I think we have all links on the mailing list web page. The
>>> one
>>>> thing which I really really miss is place on the download site where I
>>> will
>>>> be able to download Nightly Build -
>>> 
>>> Please read this [1] about linking to nightly builds.
>>> 
>>> Justin
>>> 
>>> 1. 
>>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.apac
>>>he.org%2Flegal%2Frelease-policy.html%23host-rc&data=02%7C01%7C%7C022f804
>>>829b540f2b8ea08d5282daf79%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6
>>>36459099045827202&sdata=YpwkTlmVVziJiXkXkD3R8mxDxPJPNn5CGm%2BHMz%2BSBwE%
>>>3D&reserved=0 <
>>> 
>>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.apac
>>>he.org%2Flegal%2Frelease-policy.html%23host-rc&data=02%7C01%7C%7C022f804
>>>829b540f2b8ea08d5282daf79%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6
>>>36459099045827202&sdata=YpwkTlmVVziJiXkXkD3R8mxDxPJPNn5CGm%2BHMz%2BSBwE%
>>>3D&reserved=0>
>> 
>> 
>> 
>> 
>> -- 
>> Carlos Rovira
>> 
>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%
>>2Fcarlosrovira&data=02%7C01%7C%7C022f804829b540f2b8ea08d5282daf79%7Cfa7b1
>>b5a7b34438794aed2c178decee1%7C0%7C0%7C636459099045827202&sdata=lvwM%2BmBW
>>p%2FhvTcq7Vy%2Fi9lVbyiNq%2Btzr25lC2V3whBU%3D&reserved=0
>

Re: Release Philosophy (was Re: [Website] Getting content ready to publish)

[Niclas Hedhman <ni...@hedhman.org>]

In general, I agree with everything said here, but I would like to clarify
that the "better than last" also needs to address known shortcomings. E.g.
Dave's example, GPL has been with us for quite a while, but we now know
about it, we can't simply "well, the release is better than last one, so
let's not worry about the GPL this time either". That would not be
acceptable, as it goes against the grain of ASF principles. If however,
there was a line missing in NOTICE and we cut a release and knowing such
line was missing, it is not a big deal.

With RAT, many simple mistakes are avoided.
With a fully automated release process, cutting a release candidate is
cheap/fast.

"Release Early, Release Often" is more important than every "i" dotted and
every "t" crossed.


As for nightly builds; As long as it is absolutely clear that it is not
Apache releases and do not use the /dist (which triggers dozens/hundreds of
download mirrors), then you have a great deal of freedom. Look at other
projects [1], especially those that has been doing it for quite a while.

[1] https://ant.apache.org/nightlies.html
[2] https://cwiki.apache.org/confluence/display/DIRxSTUDIO/Nightly+Builds
[3] https://wiki.apache.org/solr/NightlyBuilds

Cheers
Niclas

On Sat, Nov 11, 2017 at 3:02 AM, Alex Harui <ah...@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" <da...@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 <ah...@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
> >> (compiler, framework), or we could have 3 (one per repo: compiler,
> >> typedefs, framework), or we could have 1 by bundling the 3 repos
> >>together.
> >> And whatever we choose now, we can change later, since some day there
> >> will probably be a Tour de Royale or something like that.  Also, I have
> >> made changes to Royale release packaging so that they should not be
> >> dependent on an Installer release.  IOW, we have hopefully simplified
> >>our
> >> releases (assuming folks are ok with the new ways to get SWF-related
> >>code).
> >>
> >> The main Apache philosophy, AIUI, is simply that the foundation cannot
> >>be
> >> telling the general public to download source that has not been vetted
> >>by
> >> the Foundation (actually a PMC) as being entirely open source under
> >> licenses compatible with ALv2.  Yes, there are exceptions for Cat B and
> >> Cat X with proper handling, but that's the primary principle:  the
> >>general
> >> public must only be consuming things we've reviewed and approved.  A
> >> nightly build simply hasn't undergone that level of review.
> >>
> >> Meanwhile, there appears to be distinctions at Apache about user-facing
> >> and developer-facing "channels".  For sure, there is a dev@ and users@
> >> mailing list, and there appears to be a notion of user-facing vs
> >> developer-facing web sites or pages.  I haven't found a definitive
> >> description of the latter, though.
> >>
> >> In theory, folks who are reading dev@ have their "developer" hat on,
> and
> >> so we can freely discuss nightly builds and where to get them on dev@.
> >> AIUI, we can even tell an individual or group on 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
> >> (compiler, framework), or we could have 3 (one per repo: compiler,
> >> typedefs, framework), or we could have 1 by bundling the 3 repos
> >>together.
> >> And whatever we choose now, we can change later, since some day there
> >> will probably be a Tour de Royale or something like that.  Also, I have
> >> made changes to Royale release packaging so that they should not be
> >> dependent on an Installer release.  IOW, we have hopefully simplified
> >>our
> >> releases (assuming folks are ok with the new ways to get SWF-related
> >>code).
> >>
> >> The main Apache philosophy, AIUI, is simply that the foundation cannot
> >>be
> >> telling the general public to download source that has not been vetted
> >>by
> >> the Foundation (actually a PMC) as being entirely open source under
> >> licenses compatible with ALv2.  Yes, there are exceptions for Cat B and
> >> Cat X with proper handling, but that's the primary principle:  the
> >>general
> >> public must only be consuming things we've reviewed and approved.  A
> >> nightly build simply hasn't undergone that level of review.
> >>
> >> Meanwhile, there appears to be distinctions at Apache about user-facing
> >> and developer-facing "channels".  For sure, there is a dev@ and users@
> >> mailing list, and there appears to be a notion of user-facing vs
> >> developer-facing web sites or pages.  I haven't found a definitive
> >> description of the latter, though.
> >>
> >> In theory, folks who are reading dev@ have their "developer" hat on,
> and
> >> so we can freely discuss nightly builds and where to get them on dev@.
> >> AIUI, we can even tell an individual or group on users@ to grab a
> >>nightly
> >> and see if it fixes a bug they've been experiencing or try a new feature
> >> as long as we use the right words that the nightly is not a release for
> >> the general public.
> >>
> >> I'm not sure how to do the same on a web site.  AIUI, the main page at
> >> royale.a.o is supposed to be a combination of user-facing and
> >> developer-facing content.  It must instruct the general public where to
> >> get releases, and it must also instruct newcomers as to where to get the
> >> source code and participate.
> >>
> >> But to tie all the above to the subject title, I want to mention
> >>something
> >> Roy told me recently.  Roy said that for many projects, the criteria for
> >> voting on a release is "better than the last release" and "not illegal".
> >> And "not illegal" truly means breaking a law, not whether the release is
> >> perfectly compliant with some Apache policy.  Apache Policy does not
> >> always support compliance with some law.  Much of it is for consistency
> >> and convenience.
> >>
> >> For those of you who have participated in Apache Flex releases, the
> >> philosophy there was quite different.  There was lots of nitpicking done
> >> at the last phases of the release process.  This made some sense for
> >> Apache Flex as each release was targeted at 100's if not 1000's of
> >> existing Flex customers that may have had mission critical applications
> >> relying on certain code-paths.  However, for Royale, at least for the
> >>next
> >> few years, I think we should adopt the "better and not illegal"
> >> philosophy.  I think that philosophy, combined with fewer release
> >> artifacts, should allow us to release way more often than we used to.
> >>And
> >> that will reduce the importance of linking to nightly builds off our web
> >> pages.  Nobody should really need to look at our web pages for links to
> >> the nightly builds because they should be following the dev@ list or we
> >> will be telling someone on users@ to try some nightly and giving them a
> >> link in the email.  IOW, the links to the nightly should just keep
> >>coming
> >> up in email conversation, and as long as we are careful on users@, we
> >> should be fine.
> >>
> >> I think I am done with renaming references to Flex in the framework.  We
> >> could cut a release now if we want to, especially with a "better and not
> >> illegal" philosophy.  I am choosing to wait on the release in order to
> >> finish a major refactoring of the compiler because I saw some folks
> >> struggle to get the repos to build and because the refactoring is needed
> >> to remove the last batch of Flex references from the compiler.  The
> >> refactoring is intended to make building from the repos much simpler and
> >> leave a better first impression for those who try it, so I thought that
> >>we
> >> should wait to make "first release" noise until we have smoothed that
> >>out,
> >> but I'm fine if we want to ship what we have now.  This refactoring
> >>could
> >> be at least another week or two of work.  Cutting a release with this
> >>new
> >> philosophy should be much less than that although I suspect folks may
> >>have
> >> feedback on the new packaging.
> >>
> >> Thoughts?
> >> -Alex
> >>
> >>> On 11/10/17, 3:24 AM, "Harbs" <ha...@gmail.com> wrote:
> >>>
> >>> We’re not tied. It just needs to be on a different page to avoid users
> >>> downloading nightly versions by mistake.
> >>>
> >>> There needs to be two download pages:
> >>>
> >>> 1. For “normal” users who only want to use stable releases.
> >>> 2. Framework developers and users who want to use the latest.
> >>>
> >>> Right now, we don’t have content for #1.
> >>>
> >>> Harbs
> >>>
> >>>> On Nov 10, 2017, at 12:31 PM, Carlos Rovira <ca...@apache.org>
> >>>> wrote:
> >>>>
> >>>> Hi Piotr, Justin,
> >>>>
> >>>> as Justin, comments, I think we are tied until we get our first
> >>>>release.
> >>>> It really doesn't matter to me since "downloads" page is something
> >>>> currently not widely used is project like us.
> >>>> As always, I like to refer to competence, and they use to point to NPM
> >>>> or
> >>>> Github and not post releases.
> >>>> We can do it, but for me this is to conform with old habits. We should
> >>>> expect that "young devs" will go directly to NPM
> >>>> to get Apache Royale ;)
> >>>>
> >>>>
> >>>> 2017-11-10 0:30 GMT+01:00 Justin Mclean <ju...@classsoftware.com>:
> >>>>
> >>>>> Hi,
> >>>>>
> >>>>>> Great job. I think we have all links on the mailing list web page.
> >>>>>>The
> >>>>> one
> >>>>>> thing which I really really miss is place on the download site
> >>>>>>where I
> >>>>> will
> >>>>>> be able to download Nightly Build -
> >>>>>
> >>>>> Please read this [1] about linking to nightly builds.
> >>>>>
> >>>>> Justin
> >>>>>
> >>>>> 1.
> >>>>>
> >>>>>https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fwww.ap
> >>>>>ac
> >>>>>
> >>>>>he.org%2Flegal%2Frelease-policy.html%23host-rc&data=02%
> 7C01%7C%7C022f8
> >>>>>04
> >>>>>
> >>>>>829b540f2b8ea08d5282daf79%7Cfa7b1b5a7b34438794aed2c178de
> cee1%7C0%7C0%7
> >>>>>C6
> >>>>>
> >>>>>36459099045827202&sdata=YpwkTlmVVziJiXkXkD3R8mxDxPJPNn
> 5CGm%2BHMz%2BSBw
> >>>>>E%
> >>>>> 3D&reserved=0 <
> >>>>>
> >>>>>
> >>>>>https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fwww.ap
> >>>>>ac
> >>>>>
> >>>>>he.org%2Flegal%2Frelease-policy.html%23host-rc&data=02%
> 7C01%7C%7C022f8
> >>>>>04
> >>>>>
> >>>>>829b540f2b8ea08d5282daf79%7Cfa7b1b5a7b34438794aed2c178de
> cee1%7C0%7C0%7
> >>>>>C6
> >>>>>
> >>>>>36459099045827202&sdata=YpwkTlmVVziJiXkXkD3R8mxDxPJPNn
> 5CGm%2BHMz%2BSBw
> >>>>>E%
> >>>>> 3D&reserved=0>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Carlos Rovira
> >>>>
> >>>>
> >>>>https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fabout.m
> >>>>e%
> >>>>
> >>>>2Fcarlosrovira&data=02%7C01%7C%7C022f804829b540f2b8ea08d5282d
> af79%7Cfa7
> >>>>b1
> >>>>
> >>>>b5a7b34438794aed2c178decee1%7C0%7C0%7C636459099045827202&
> sdata=lvwM%2Bm
> >>>>BW
> >>>> p%2FhvTcq7Vy%2Fi9lVbyiNq%2Btzr25lC2V3whBU%3D&reserved=0
> >>>
> >>
> >
>
>


-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java

Re: Release Philosophy (was Re: [Website] Getting content ready to publish)

[Carlos Rovira <ca...@apache.org>]

Hi Piotr,

I removed that part, please, check.
As well I sent you private for access info

thanks

2017-11-13 13:21 GMT+01:00 Piotr Zarzycki <pi...@gmail.com>:

> That's what I think so.
>
> I was trying to also login into account, but when I'm going to admin page
> it doesn't ask me for a new password, but rather redirect me to the login
> page. I tried to reset password, but it didn't help.
>
> Piotr
>
>
> 2017-11-13 13:11 GMT+01:00 Carlos Rovira <ca...@codeoscopic.com>:
>
> > Hi Piotr,
> >
> > I'm fine with the decisions you would like to take regarding that links.
> I
> > just setup an initial layout.
> >
> > So, if I understand well I must to remove only the status link?
> >
> >
> >
> > 2017-11-13 12:42 GMT+01:00 Piotr Zarzycki <pi...@gmail.com>:
> >
> > > Carlos,
> > >
> > > I'm not convinced that we should move framework build from Alex's Azure
> > PC.
> > > It is really convenient if something went wrong to just connect with
> the
> > > PC. If you would like to have distribution build under Apache umbrella
> > you
> > > will need to fight with Infra about that. Maven is building on Apache
> > > servers, Chris handle that. I would rather not invest the time in that
> > > since we have working everything on Alex PC, but that's just mine
> > > convenient and save time view. :)
> > >
> > > Piotr
> > >
> > >
> > > 2017-11-13 12:36 GMT+01:00 Carlos Rovira <ca...@apache.org>:
> > >
> > > > 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 <piotrzarzycki21@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 <
> piotrzarzycki21@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 <
> carlosrovira@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 <
> carlosrovira@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 <aharui@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.rovira@gmail.com on behalf of
> > > > Carlos
> > > > > >> >> Rovira" <carlos.rovira@gmail.com on behalf of
> > > > > carlosrovira@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 <
> dave2wave@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
> > > > > <aharui@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" <
> > > dave2wave@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
> > > > > >> <aharui@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
> > > >
> > >
> > >
> > >
> > > --
> > >
> > > Piotr Zarzycki
> > >
> > > Patreon: *https://www.patreon.com/piotrzarzycki
> > > <https://www.patreon.com/piotrzarzycki>*
> > >
> >
> >
> >
> > --
> >
> > <http://www.codeoscopic.com>
> >
> > Carlos Rovira
> >
> > Director General
> >
> > M: +34 607 22 60 05
> >
> > http://www.codeoscopic.com
> >
> >
> > Conócenos en 1 minuto! <https://avant2.es/#video>
> >
> >
> > Este mensaje se dirige exclusivamente a su destinatario y puede contener
> > información privilegiada o confidencial. Si ha recibido este mensaje por
> > error, le rogamos que nos lo comunique inmediatamente por esta misma vía
> y
> > proceda a su destrucción.
> >
> > De la vigente Ley Orgánica de Protección de Datos (15/1999), le
> comunicamos
> > que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC
> > S.A. La finalidad de dicho tratamiento es facilitar la prestación del
> > servicio o información solicitados, teniendo usted derecho de acceso,
> > rectificación, cancelación y oposición de sus datos dirigiéndose a
> nuestras
> > oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación
> > necesaria.
> >
>
>
>
> --
>
> Piotr Zarzycki
>
> Patreon: *https://www.patreon.com/piotrzarzycki
> <https://www.patreon.com/piotrzarzycki>*
>



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

Re: Release Philosophy (was Re: [Website] Getting content ready to publish)

[Piotr Zarzycki <pi...@gmail.com>]

That's what I think so.

I was trying to also login into account, but when I'm going to admin page
it doesn't ask me for a new password, but rather redirect me to the login
page. I tried to reset password, but it didn't help.

Piotr


2017-11-13 13:11 GMT+01:00 Carlos Rovira <ca...@codeoscopic.com>:

> Hi Piotr,
>
> I'm fine with the decisions you would like to take regarding that links. I
> just setup an initial layout.
>
> So, if I understand well I must to remove only the status link?
>
>
>
> 2017-11-13 12:42 GMT+01:00 Piotr Zarzycki <pi...@gmail.com>:
>
> > Carlos,
> >
> > I'm not convinced that we should move framework build from Alex's Azure
> PC.
> > It is really convenient if something went wrong to just connect with the
> > PC. If you would like to have distribution build under Apache umbrella
> you
> > will need to fight with Infra about that. Maven is building on Apache
> > servers, Chris handle that. I would rather not invest the time in that
> > since we have working everything on Alex PC, but that's just mine
> > convenient and save time view. :)
> >
> > Piotr
> >
> >
> > 2017-11-13 12:36 GMT+01:00 Carlos Rovira <ca...@apache.org>:
> >
> > > 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 <pi...@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 <piotrzarzycki21@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 <carlosrovira@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 <carlosrovira@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 <aharui@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.rovira@gmail.com on behalf of
> > > Carlos
> > > > >> >> Rovira" <carlos.rovira@gmail.com on behalf of
> > > > carlosrovira@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 <dave2wave@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
> > > > <aharui@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" <
> > dave2wave@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
> > > > >> <aharui@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
> > >
> >
> >
> >
> > --
> >
> > Piotr Zarzycki
> >
> > Patreon: *https://www.patreon.com/piotrzarzycki
> > <https://www.patreon.com/piotrzarzycki>*
> >
>
>
>
> --
>
> <http://www.codeoscopic.com>
>
> Carlos Rovira
>
> Director General
>
> M: +34 607 22 60 05
>
> http://www.codeoscopic.com
>
>
> Conócenos en 1 minuto! <https://avant2.es/#video>
>
>
> Este mensaje se dirige exclusivamente a su destinatario y puede contener
> información privilegiada o confidencial. Si ha recibido este mensaje por
> error, le rogamos que nos lo comunique inmediatamente por esta misma vía y
> proceda a su destrucción.
>
> De la vigente Ley Orgánica de Protección de Datos (15/1999), le comunicamos
> que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC
> S.A. La finalidad de dicho tratamiento es facilitar la prestación del
> servicio o información solicitados, teniendo usted derecho de acceso,
> rectificación, cancelación y oposición de sus datos dirigiéndose a nuestras
> oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación
> necesaria.
>



-- 

Piotr Zarzycki

Patreon: *https://www.patreon.com/piotrzarzycki
<https://www.patreon.com/piotrzarzycki>*

Re: Release Philosophy (was Re: [Website] Getting content ready to publish)

[Carlos Rovira <ca...@codeoscopic.com>]

Hi Piotr,

I'm fine with the decisions you would like to take regarding that links. I
just setup an initial layout.

So, if I understand well I must to remove only the status link?



2017-11-13 12:42 GMT+01:00 Piotr Zarzycki <pi...@gmail.com>:

> Carlos,
>
> I'm not convinced that we should move framework build from Alex's Azure PC.
> It is really convenient if something went wrong to just connect with the
> PC. If you would like to have distribution build under Apache umbrella you
> will need to fight with Infra about that. Maven is building on Apache
> servers, Chris handle that. I would rather not invest the time in that
> since we have working everything on Alex PC, but that's just mine
> convenient and save time view. :)
>
> Piotr
>
>
> 2017-11-13 12:36 GMT+01:00 Carlos Rovira <ca...@apache.org>:
>
> > 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 <pi...@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 <pi...@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 <ca...@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 <ca...@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 <ah...@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.rovira@gmail.com on behalf of
> > Carlos
> > > >> >> Rovira" <carlos.rovira@gmail.com on behalf of
> > > carlosrovira@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 <da...@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
> > > <aharui@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" <
> dave2wave@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
> > > >> <aharui@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
> >
>
>
>
> --
>
> Piotr Zarzycki
>
> Patreon: *https://www.patreon.com/piotrzarzycki
> <https://www.patreon.com/piotrzarzycki>*
>



-- 

<http://www.codeoscopic.com>

Carlos Rovira

Director General

M: +34 607 22 60 05

http://www.codeoscopic.com


Conócenos en 1 minuto! <https://avant2.es/#video>


Este mensaje se dirige exclusivamente a su destinatario y puede contener
información privilegiada o confidencial. Si ha recibido este mensaje por
error, le rogamos que nos lo comunique inmediatamente por esta misma vía y
proceda a su destrucción.

De la vigente Ley Orgánica de Protección de Datos (15/1999), le comunicamos
que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC
S.A. La finalidad de dicho tratamiento es facilitar la prestación del
servicio o información solicitados, teniendo usted derecho de acceso,
rectificación, cancelación y oposición de sus datos dirigiéndose a nuestras
oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación
necesaria.

Re: Release Philosophy (was Re: [Website] Getting content ready to publish)

[Piotr Zarzycki <pi...@gmail.com>]

Carlos,

I'm not convinced that we should move framework build from Alex's Azure PC.
It is really convenient if something went wrong to just connect with the
PC. If you would like to have distribution build under Apache umbrella you
will need to fight with Infra about that. Maven is building on Apache
servers, Chris handle that. I would rather not invest the time in that
since we have working everything on Alex PC, but that's just mine
convenient and save time view. :)

Piotr


2017-11-13 12:36 GMT+01:00 Carlos Rovira <ca...@apache.org>:

> 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 <pi...@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 <pi...@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 <ca...@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 <ca...@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 <ah...@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.rovira@gmail.com on behalf of
> Carlos
> > >> >> Rovira" <carlos.rovira@gmail.com on behalf of
> > carlosrovira@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 <da...@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
> > <aharui@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" <da...@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
> > >> <aharui@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
>



-- 

Piotr Zarzycki

Patreon: *https://www.patreon.com/piotrzarzycki
<https://www.patreon.com/piotrzarzycki>*

Re: Release Philosophy (was Re: [Website] Getting content ready to publish)

[Carlos Rovira <ca...@apache.org>]

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 <pi...@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 <pi...@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 <ca...@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 <ca...@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 <ah...@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.rovira@gmail.com on behalf of Carlos
> >> >> Rovira" <carlos.rovira@gmail.com on behalf of
> carlosrovira@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 <da...@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
> <aharui@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" <da...@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
> >> <aharui@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

Re: Release Philosophy (was Re: [Website] Getting content ready to publish)

[Piotr Zarzycki <pi...@gmail.com>]

I'm sorry! CARLOS I meant :)

2017-11-12 20:04 GMT+01:00 Piotr Zarzycki <pi...@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 <pi...@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 <ca...@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 <ca...@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 <ah...@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.rovira@gmail.com on behalf of Carlos
>>> >> Rovira" <carlos.rovira@gmail.com on behalf of carlosrovira@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 <da...@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
>>> <ah...@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" <da...@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
>>> <aharui@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>*

Re: Release Philosophy (was Re: [Website] Getting content ready to publish)

[Piotr Zarzycki <pi...@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 <pi...@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 <ca...@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 <ca...@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 <ah...@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.rovira@gmail.com on behalf of Carlos
>> >> Rovira" <carlos.rovira@gmail.com on behalf of carlosrovira@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 <da...@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 <aharui@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" <da...@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
>> <aharui@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>*

Re: Release Philosophy (was Re: [Website] Getting content ready to publish)

[Carlos Rovira <ca...@apache.org>]

Hi Piotr
thanks, just changed the links to the ones you provide me and increase font
size in message box. :)

2017-11-12 18:42 GMT+01:00 Piotr Zarzycki <pi...@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 <ca...@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 <ca...@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 <ah...@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.rovira@gmail.com on behalf of Carlos
> > >> Rovira" <carlos.rovira@gmail.com on behalf of carlosrovira@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 <da...@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
> <aharui@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" <da...@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
> > <aharui@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>*
>



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

Re: Release Philosophy (was Re: [Website] Getting content ready to publish)

[Piotr Zarzycki <pi...@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 <ca...@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 <ca...@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 <ah...@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.rovira@gmail.com on behalf of Carlos
> >> Rovira" <carlos.rovira@gmail.com on behalf of carlosrovira@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 <da...@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 <aharui@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" <da...@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
> <aharui@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>*

Re: Release Philosophy (was Re: [Website] Getting content ready to publish)

[Carlos Rovira <ca...@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 <ca...@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 <ah...@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.rovira@gmail.com on behalf of Carlos
>> Rovira" <carlos.rovira@gmail.com on behalf of carlosrovira@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 <da...@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 <ah...@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" <da...@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 <aharui@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

Re: Release Philosophy (was Re: [Website] Getting content ready to publish)

[Carlos Rovira <ca...@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 <ah...@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.rovira@gmail.com on behalf of Carlos
> Rovira" <carlos.rovira@gmail.com on behalf of carlosrovira@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 <da...@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 <ah...@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" <da...@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 <ah...@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%7C4ddfd5d3bb8e44f9b4c508d52873
> f24b%7Cfa7b1b5
> >a7b34438794aed2c178decee1%7C0%7C0%7C636459400811686261&
> sdata=AONFxld%2FTJz
> >zDM%2Frjf0g6L8PfwqlpJHkF9RVZII1TWo%3D&reserved=0
>
>


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

Re: Release Philosophy (was Re: [Website] Getting content ready to publish)

[Alex Harui <ah...@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.rovira@gmail.com on behalf of Carlos
Rovira" <carlos.rovira@gmail.com on behalf of carlosrovira@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 <da...@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 <ah...@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" <da...@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 <ah...@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

Re: Release Philosophy (was Re: [Website] Getting content ready to publish)

[Carlos Rovira <ca...@apache.org>]

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 <da...@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 <ah...@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" <da...@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 <ah...@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
http://about.me/carlosrovira

Re: Release Philosophy (was Re: [Website] Getting content ready to publish)

[Carlos Rovira <ca...@apache.org>]

Hi,

could someone post here the links to post in downloads page for now?

Thanks!

2017-11-10 23:57 GMT+01:00 Dave Fisher <da...@comcast.net>:

> +1.
>
> Sent from my iPhone
>
> > On Nov 10, 2017, at 2:01 PM, OmPrakash Muppirala <bi...@gmail.com>
> wrote:
> >
> > I think it is okay for us to have a 'Nightly builds' section on our
> website
> > like these projects:
> >
> > http://jmeter.apache.org/nightly.html
> > https://wiki.apache.org/solr/NightlyBuilds
> > https://ant.apache.org/nightlies.html
> > https://poi.apache.org/download.html#nightly
> > https://lucene.apache.org/core/developer.html
> >
> > Of course, we need to say in big bold letters that these builds should
> not
> > be used in production, and that they are not supported by the Apache
> Royale
> > team.  They are there only for testing purposes and that they can discuss
> > issues found in nightly builds in the dev@royale.apache.org list.
> >
> > Just my 2 cents.
> >
> > Thanks,
> > Om
> >
> >
> > On Fri, Nov 10, 2017 at 12:47 PM, Piotr Zarzycki <
> piotrzarzycki21@gmail.com>
> > wrote:
> >
> >> I think that is the solution for nightly builds. We should state on the
> >> website that we can provide Nightly Builds when someone ask on dev,
> users.
> >> Can it be ok ? I like such idea.
> >>
> >> I agree with you Alex that we should wait for the release for your
> >> refactoring, but we need to have statement above as fast as we can,
> cause
> >> there from time to time is asking where I can find artifacts.
> >>
> >> Piotr
> >>
> >>
> >> 2017-11-10 20:12 GMT+01:00 Dave Fisher <da...@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 <ah...@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" <da...@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 <ah...@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
> >>>>>> (
> >>>
> >>>
> >>
> >>
> >> --
> >>
> >> Piotr Zarzycki
> >>
> >> Patreon: *https://www.patreon.com/piotrzarzycki
> >> <https://www.patreon.com/piotrzarzycki>*
> >>
>
>


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

Re: Release Philosophy (was Re: [Website] Getting content ready to publish)

[Dave Fisher <da...@comcast.net>]

+1.

Sent from my iPhone

> On Nov 10, 2017, at 2:01 PM, OmPrakash Muppirala <bi...@gmail.com> wrote:
> 
> I think it is okay for us to have a 'Nightly builds' section on our website
> like these projects:
> 
> http://jmeter.apache.org/nightly.html
> https://wiki.apache.org/solr/NightlyBuilds
> https://ant.apache.org/nightlies.html
> https://poi.apache.org/download.html#nightly
> https://lucene.apache.org/core/developer.html
> 
> Of course, we need to say in big bold letters that these builds should not
> be used in production, and that they are not supported by the Apache Royale
> team.  They are there only for testing purposes and that they can discuss
> issues found in nightly builds in the dev@royale.apache.org list.
> 
> Just my 2 cents.
> 
> Thanks,
> Om
> 
> 
> On Fri, Nov 10, 2017 at 12:47 PM, Piotr Zarzycki <pi...@gmail.com>
> wrote:
> 
>> I think that is the solution for nightly builds. We should state on the
>> website that we can provide Nightly Builds when someone ask on dev, users.
>> Can it be ok ? I like such idea.
>> 
>> I agree with you Alex that we should wait for the release for your
>> refactoring, but we need to have statement above as fast as we can, cause
>> there from time to time is asking where I can find artifacts.
>> 
>> Piotr
>> 
>> 
>> 2017-11-10 20:12 GMT+01:00 Dave Fisher <da...@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 <ah...@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" <da...@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 <ah...@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
>>>>>> (
>>> 
>>> 
>> 
>> 
>> --
>> 
>> Piotr Zarzycki
>> 
>> Patreon: *https://www.patreon.com/piotrzarzycki
>> <https://www.patreon.com/piotrzarzycki>*
>> 

Re: Release Philosophy (was Re: [Website] Getting content ready to publish)

[Niclas Hedhman <ni...@hedhman.org>]

:-)  Well said Om, and if I had waited a few seconds, I wouldn't have
repeated ourselves....

On Sat, Nov 11, 2017 at 6:01 AM, OmPrakash Muppirala <bi...@gmail.com>
wrote:

> I think it is okay for us to have a 'Nightly builds' section on our website
> like these projects:
>
> http://jmeter.apache.org/nightly.html
> https://wiki.apache.org/solr/NightlyBuilds
> https://ant.apache.org/nightlies.html
> https://poi.apache.org/download.html#nightly
> https://lucene.apache.org/core/developer.html
>
> Of course, we need to say in big bold letters that these builds should not
> be used in production, and that they are not supported by the Apache Royale
> team.  They are there only for testing purposes and that they can discuss
> issues found in nightly builds in the dev@royale.apache.org list.
>
> Just my 2 cents.
>
> Thanks,
> Om
>
>
> On Fri, Nov 10, 2017 at 12:47 PM, Piotr Zarzycki <
> piotrzarzycki21@gmail.com>
> wrote:
>
> > I think that is the solution for nightly builds. We should state on the
> > website that we can provide Nightly Builds when someone ask on dev,
> users.
> > Can it be ok ? I like such idea.
> >
> > I agree with you Alex that we should wait for the release for your
> > refactoring, but we need to have statement above as fast as we can, cause
> > there from time to time is asking where I can find artifacts.
> >
> > Piotr
> >
> >
> > 2017-11-10 20:12 GMT+01:00 Dave Fisher <da...@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 <ah...@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" <da...@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 <aharui@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
> > > >>> (
> > >
> > >
> >
> >
> > --
> >
> > Piotr Zarzycki
> >
> > Patreon: *https://www.patreon.com/piotrzarzycki
> > <https://www.patreon.com/piotrzarzycki>*
> >
>



-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java

Re: Release Philosophy (was Re: [Website] Getting content ready to publish)

[OmPrakash Muppirala <bi...@gmail.com>]

I think it is okay for us to have a 'Nightly builds' section on our website
like these projects:

http://jmeter.apache.org/nightly.html
https://wiki.apache.org/solr/NightlyBuilds
https://ant.apache.org/nightlies.html
https://poi.apache.org/download.html#nightly
https://lucene.apache.org/core/developer.html

Of course, we need to say in big bold letters that these builds should not
be used in production, and that they are not supported by the Apache Royale
team.  They are there only for testing purposes and that they can discuss
issues found in nightly builds in the dev@royale.apache.org list.

Just my 2 cents.

Thanks,
Om


On Fri, Nov 10, 2017 at 12:47 PM, Piotr Zarzycki <pi...@gmail.com>
wrote:

> I think that is the solution for nightly builds. We should state on the
> website that we can provide Nightly Builds when someone ask on dev, users.
> Can it be ok ? I like such idea.
>
> I agree with you Alex that we should wait for the release for your
> refactoring, but we need to have statement above as fast as we can, cause
> there from time to time is asking where I can find artifacts.
>
> Piotr
>
>
> 2017-11-10 20:12 GMT+01:00 Dave Fisher <da...@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 <ah...@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" <da...@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 <ah...@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
> > >>> (
> >
> >
>
>
> --
>
> Piotr Zarzycki
>
> Patreon: *https://www.patreon.com/piotrzarzycki
> <https://www.patreon.com/piotrzarzycki>*
>

Re: Release Philosophy (was Re: [Website] Getting content ready to publish)

[Piotr Zarzycki <pi...@gmail.com>]

I think that is the solution for nightly builds. We should state on the
website that we can provide Nightly Builds when someone ask on dev, users.
Can it be ok ? I like such idea.

I agree with you Alex that we should wait for the release for your
refactoring, but we need to have statement above as fast as we can, cause
there from time to time is asking where I can find artifacts.

Piotr


2017-11-10 20:12 GMT+01:00 Dave Fisher <da...@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 <ah...@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" <da...@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 <ah...@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
> >>> (
>
>


-- 

Piotr Zarzycki

Patreon: *https://www.patreon.com/piotrzarzycki
<https://www.patreon.com/piotrzarzycki>*

Re: Release Philosophy (was Re: [Website] Getting content ready to publish)

[Dave Fisher <da...@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 <ah...@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" <da...@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 <ah...@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
>>> (

Re: Release Philosophy (was Re: [Website] Getting content ready to publish)

[Alex Harui <ah...@adobe.com.INVALID>]

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" <da...@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 <ah...@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
>> (compiler, framework), or we could have 3 (one per repo: compiler,
>> typedefs, framework), or we could have 1 by bundling the 3 repos
>>together.
>> And whatever we choose now, we can change later, since some day there
>> will probably be a Tour de Royale or something like that.  Also, I have
>> made changes to Royale release packaging so that they should not be
>> dependent on an Installer release.  IOW, we have hopefully simplified
>>our
>> releases (assuming folks are ok with the new ways to get SWF-related
>>code).
>> 
>> The main Apache philosophy, AIUI, is simply that the foundation cannot
>>be
>> telling the general public to download source that has not been vetted
>>by
>> the Foundation (actually a PMC) as being entirely open source under
>> licenses compatible with ALv2.  Yes, there are exceptions for Cat B and
>> Cat X with proper handling, but that's the primary principle:  the
>>general
>> public must only be consuming things we've reviewed and approved.  A
>> nightly build simply hasn't undergone that level of review.
>> 
>> Meanwhile, there appears to be distinctions at Apache about user-facing
>> and developer-facing "channels".  For sure, there is a dev@ and users@
>> mailing list, and there appears to be a notion of user-facing vs
>> developer-facing web sites or pages.  I haven't found a definitive
>> description of the latter, though.
>> 
>> In theory, folks who are reading dev@ have their "developer" hat on, and
>> so we can freely discuss nightly builds and where to get them on dev@.
>> AIUI, we can even tell an individual or group on 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
>> (compiler, framework), or we could have 3 (one per repo: compiler,
>> typedefs, framework), or we could have 1 by bundling the 3 repos
>>together.
>> And whatever we choose now, we can change later, since some day there
>> will probably be a Tour de Royale or something like that.  Also, I have
>> made changes to Royale release packaging so that they should not be
>> dependent on an Installer release.  IOW, we have hopefully simplified
>>our
>> releases (assuming folks are ok with the new ways to get SWF-related
>>code).
>> 
>> The main Apache philosophy, AIUI, is simply that the foundation cannot
>>be
>> telling the general public to download source that has not been vetted
>>by
>> the Foundation (actually a PMC) as being entirely open source under
>> licenses compatible with ALv2.  Yes, there are exceptions for Cat B and
>> Cat X with proper handling, but that's the primary principle:  the
>>general
>> public must only be consuming things we've reviewed and approved.  A
>> nightly build simply hasn't undergone that level of review.
>> 
>> Meanwhile, there appears to be distinctions at Apache about user-facing
>> and developer-facing "channels".  For sure, there is a dev@ and users@
>> mailing list, and there appears to be a notion of user-facing vs
>> developer-facing web sites or pages.  I haven't found a definitive
>> description of the latter, though.
>> 
>> In theory, folks who are reading dev@ have their "developer" hat on, and
>> so we can freely discuss nightly builds and where to get them on dev@.
>> AIUI, we can even tell an individual or group on users@ to grab a
>>nightly
>> and see if it fixes a bug they've been experiencing or try a new feature
>> as long as we use the right words that the nightly is not a release for
>> the general public.
>> 
>> I'm not sure how to do the same on a web site.  AIUI, the main page at
>> royale.a.o is supposed to be a combination of user-facing and
>> developer-facing content.  It must instruct the general public where to
>> get releases, and it must also instruct newcomers as to where to get the
>> source code and participate.
>> 
>> But to tie all the above to the subject title, I want to mention
>>something
>> Roy told me recently.  Roy said that for many projects, the criteria for
>> voting on a release is "better than the last release" and "not illegal".
>> And "not illegal" truly means breaking a law, not whether the release is
>> perfectly compliant with some Apache policy.  Apache Policy does not
>> always support compliance with some law.  Much of it is for consistency
>> and convenience.
>> 
>> For those of you who have participated in Apache Flex releases, the
>> philosophy there was quite different.  There was lots of nitpicking done
>> at the last phases of the release process.  This made some sense for
>> Apache Flex as each release was targeted at 100's if not 1000's of
>> existing Flex customers that may have had mission critical applications
>> relying on certain code-paths.  However, for Royale, at least for the
>>next
>> few years, I think we should adopt the "better and not illegal"
>> philosophy.  I think that philosophy, combined with fewer release
>> artifacts, should allow us to release way more often than we used to.
>>And
>> that will reduce the importance of linking to nightly builds off our web
>> pages.  Nobody should really need to look at our web pages for links to
>> the nightly builds because they should be following the dev@ list or we
>> will be telling someone on users@ to try some nightly and giving them a
>> link in the email.  IOW, the links to the nightly should just keep
>>coming
>> up in email conversation, and as long as we are careful on users@, we
>> should be fine.
>> 
>> I think I am done with renaming references to Flex in the framework.  We
>> could cut a release now if we want to, especially with a "better and not
>> illegal" philosophy.  I am choosing to wait on the release in order to
>> finish a major refactoring of the compiler because I saw some folks
>> struggle to get the repos to build and because the refactoring is needed
>> to remove the last batch of Flex references from the compiler.  The
>> refactoring is intended to make building from the repos much simpler and
>> leave a better first impression for those who try it, so I thought that
>>we
>> should wait to make "first release" noise until we have smoothed that
>>out,
>> but I'm fine if we want to ship what we have now.  This refactoring
>>could
>> be at least another week or two of work.  Cutting a release with this
>>new
>> philosophy should be much less than that although I suspect folks may
>>have
>> feedback on the new packaging.
>> 
>> Thoughts?
>> -Alex
>> 
>>> On 11/10/17, 3:24 AM, "Harbs" <ha...@gmail.com> wrote:
>>> 
>>> We’re not tied. It just needs to be on a different page to avoid users
>>> downloading nightly versions by mistake.
>>> 
>>> There needs to be two download pages:
>>> 
>>> 1. For “normal” users who only want to use stable releases.
>>> 2. Framework developers and users who want to use the latest.
>>> 
>>> Right now, we don’t have content for #1.
>>> 
>>> Harbs
>>> 
>>>> On Nov 10, 2017, at 12:31 PM, Carlos Rovira <ca...@apache.org>
>>>> wrote:
>>>> 
>>>> Hi Piotr, Justin,
>>>> 
>>>> as Justin, comments, I think we are tied until we get our first
>>>>release.
>>>> It really doesn't matter to me since "downloads" page is something
>>>> currently not widely used is project like us.
>>>> As always, I like to refer to competence, and they use to point to NPM
>>>> or
>>>> Github and not post releases.
>>>> We can do it, but for me this is to conform with old habits. We should
>>>> expect that "young devs" will go directly to NPM
>>>> to get Apache Royale ;)
>>>> 
>>>> 
>>>> 2017-11-10 0:30 GMT+01:00 Justin Mclean <ju...@classsoftware.com>:
>>>> 
>>>>> Hi,
>>>>> 
>>>>>> Great job. I think we have all links on the mailing list web page.
>>>>>>The
>>>>> one
>>>>>> thing which I really really miss is place on the download site
>>>>>>where I
>>>>> will
>>>>>> be able to download Nightly Build -
>>>>> 
>>>>> Please read this [1] about linking to nightly builds.
>>>>> 
>>>>> Justin
>>>>> 
>>>>> 1. 
>>>>> 
>>>>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.ap
>>>>>ac
>>>>> 
>>>>>he.org%2Flegal%2Frelease-policy.html%23host-rc&data=02%7C01%7C%7C022f8
>>>>>04
>>>>> 
>>>>>829b540f2b8ea08d5282daf79%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7
>>>>>C6
>>>>> 
>>>>>36459099045827202&sdata=YpwkTlmVVziJiXkXkD3R8mxDxPJPNn5CGm%2BHMz%2BSBw
>>>>>E%
>>>>> 3D&reserved=0 <
>>>>> 
>>>>> 
>>>>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.ap
>>>>>ac
>>>>> 
>>>>>he.org%2Flegal%2Frelease-policy.html%23host-rc&data=02%7C01%7C%7C022f8
>>>>>04
>>>>> 
>>>>>829b540f2b8ea08d5282daf79%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7
>>>>>C6
>>>>> 
>>>>>36459099045827202&sdata=YpwkTlmVVziJiXkXkD3R8mxDxPJPNn5CGm%2BHMz%2BSBw
>>>>>E%
>>>>> 3D&reserved=0>
>>>> 
>>>> 
>>>> 
>>>> 
>>>> -- 
>>>> Carlos Rovira
>>>> 
>>>> 
>>>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.m
>>>>e%
>>>> 
>>>>2Fcarlosrovira&data=02%7C01%7C%7C022f804829b540f2b8ea08d5282daf79%7Cfa7
>>>>b1
>>>> 
>>>>b5a7b34438794aed2c178decee1%7C0%7C0%7C636459099045827202&sdata=lvwM%2Bm
>>>>BW
>>>> p%2FhvTcq7Vy%2Fi9lVbyiNq%2Btzr25lC2V3whBU%3D&reserved=0
>>> 
>> 
>

Re: Release Philosophy (was Re: [Website] Getting content ready to publish)

[Dave Fisher <da...@comcast.net>]

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 <ah...@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
> (compiler, framework), or we could have 3 (one per repo: compiler,
> typedefs, framework), or we could have 1 by bundling the 3 repos together.
> And whatever we choose now, we can change later, since some day there
> will probably be a Tour de Royale or something like that.  Also, I have
> made changes to Royale release packaging so that they should not be
> dependent on an Installer release.  IOW, we have hopefully simplified our
> releases (assuming folks are ok with the new ways to get SWF-related code).
> 
> The main Apache philosophy, AIUI, is simply that the foundation cannot be
> telling the general public to download source that has not been vetted by
> the Foundation (actually a PMC) as being entirely open source under
> licenses compatible with ALv2.  Yes, there are exceptions for Cat B and
> Cat X with proper handling, but that's the primary principle:  the general
> public must only be consuming things we've reviewed and approved.  A
> nightly build simply hasn't undergone that level of review.
> 
> Meanwhile, there appears to be distinctions at Apache about user-facing
> and developer-facing "channels".  For sure, there is a dev@ and users@
> mailing list, and there appears to be a notion of user-facing vs
> developer-facing web sites or pages.  I haven't found a definitive
> description of the latter, though.
> 
> In theory, folks who are reading dev@ have their "developer" hat on, and
> so we can freely discuss nightly builds and where to get them on dev@.
> AIUI, we can even tell an individual or group on 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
> (compiler, framework), or we could have 3 (one per repo: compiler,
> typedefs, framework), or we could have 1 by bundling the 3 repos together.
> And whatever we choose now, we can change later, since some day there
> will probably be a Tour de Royale or something like that.  Also, I have
> made changes to Royale release packaging so that they should not be
> dependent on an Installer release.  IOW, we have hopefully simplified our
> releases (assuming folks are ok with the new ways to get SWF-related code).
> 
> The main Apache philosophy, AIUI, is simply that the foundation cannot be
> telling the general public to download source that has not been vetted by
> the Foundation (actually a PMC) as being entirely open source under
> licenses compatible with ALv2.  Yes, there are exceptions for Cat B and
> Cat X with proper handling, but that's the primary principle:  the general
> public must only be consuming things we've reviewed and approved.  A
> nightly build simply hasn't undergone that level of review.
> 
> Meanwhile, there appears to be distinctions at Apache about user-facing
> and developer-facing "channels".  For sure, there is a dev@ and users@
> mailing list, and there appears to be a notion of user-facing vs
> developer-facing web sites or pages.  I haven't found a definitive
> description of the latter, though.
> 
> In theory, folks who are reading dev@ have their "developer" hat on, and
> so we can freely discuss nightly builds and where to get them on dev@.
> AIUI, we can even tell an individual or group on users@ to grab a nightly
> and see if it fixes a bug they've been experiencing or try a new feature
> as long as we use the right words that the nightly is not a release for
> the general public.
> 
> I'm not sure how to do the same on a web site.  AIUI, the main page at
> royale.a.o is supposed to be a combination of user-facing and
> developer-facing content.  It must instruct the general public where to
> get releases, and it must also instruct newcomers as to where to get the
> source code and participate.
> 
> But to tie all the above to the subject title, I want to mention something
> Roy told me recently.  Roy said that for many projects, the criteria for
> voting on a release is "better than the last release" and "not illegal".
> And "not illegal" truly means breaking a law, not whether the release is
> perfectly compliant with some Apache policy.  Apache Policy does not
> always support compliance with some law.  Much of it is for consistency
> and convenience.
> 
> For those of you who have participated in Apache Flex releases, the
> philosophy there was quite different.  There was lots of nitpicking done
> at the last phases of the release process.  This made some sense for
> Apache Flex as each release was targeted at 100's if not 1000's of
> existing Flex customers that may have had mission critical applications
> relying on certain code-paths.  However, for Royale, at least for the next
> few years, I think we should adopt the "better and not illegal"
> philosophy.  I think that philosophy, combined with fewer release
> artifacts, should allow us to release way more often than we used to.  And
> that will reduce the importance of linking to nightly builds off our web
> pages.  Nobody should really need to look at our web pages for links to
> the nightly builds because they should be following the dev@ list or we
> will be telling someone on users@ to try some nightly and giving them a
> link in the email.  IOW, the links to the nightly should just keep coming
> up in email conversation, and as long as we are careful on users@, we
> should be fine.
> 
> I think I am done with renaming references to Flex in the framework.  We
> could cut a release now if we want to, especially with a "better and not
> illegal" philosophy.  I am choosing to wait on the release in order to
> finish a major refactoring of the compiler because I saw some folks
> struggle to get the repos to build and because the refactoring is needed
> to remove the last batch of Flex references from the compiler.  The
> refactoring is intended to make building from the repos much simpler and
> leave a better first impression for those who try it, so I thought that we
> should wait to make "first release" noise until we have smoothed that out,
> but I'm fine if we want to ship what we have now.  This refactoring could
> be at least another week or two of work.  Cutting a release with this new
> philosophy should be much less than that although I suspect folks may have
> feedback on the new packaging.
> 
> Thoughts?
> -Alex
> 
>> On 11/10/17, 3:24 AM, "Harbs" <ha...@gmail.com> wrote:
>> 
>> We’re not tied. It just needs to be on a different page to avoid users
>> downloading nightly versions by mistake.
>> 
>> There needs to be two download pages:
>> 
>> 1. For “normal” users who only want to use stable releases.
>> 2. Framework developers and users who want to use the latest.
>> 
>> Right now, we don’t have content for #1.
>> 
>> Harbs
>> 
>>> On Nov 10, 2017, at 12:31 PM, Carlos Rovira <ca...@apache.org>
>>> wrote:
>>> 
>>> Hi Piotr, Justin,
>>> 
>>> as Justin, comments, I think we are tied until we get our first release.
>>> It really doesn't matter to me since "downloads" page is something
>>> currently not widely used is project like us.
>>> As always, I like to refer to competence, and they use to point to NPM
>>> or
>>> Github and not post releases.
>>> We can do it, but for me this is to conform with old habits. We should
>>> expect that "young devs" will go directly to NPM
>>> to get Apache Royale ;)
>>> 
>>> 
>>> 2017-11-10 0:30 GMT+01:00 Justin Mclean <ju...@classsoftware.com>:
>>> 
>>>> Hi,
>>>> 
>>>>> Great job. I think we have all links on the mailing list web page. The
>>>> one
>>>>> thing which I really really miss is place on the download site where I
>>>> will
>>>>> be able to download Nightly Build -
>>>> 
>>>> Please read this [1] about linking to nightly builds.
>>>> 
>>>> Justin
>>>> 
>>>> 1. 
>>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.apac
>>>> he.org%2Flegal%2Frelease-policy.html%23host-rc&data=02%7C01%7C%7C022f804
>>>> 829b540f2b8ea08d5282daf79%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6
>>>> 36459099045827202&sdata=YpwkTlmVVziJiXkXkD3R8mxDxPJPNn5CGm%2BHMz%2BSBwE%
>>>> 3D&reserved=0 <
>>>> 
>>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.apac
>>>> he.org%2Flegal%2Frelease-policy.html%23host-rc&data=02%7C01%7C%7C022f804
>>>> 829b540f2b8ea08d5282daf79%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6
>>>> 36459099045827202&sdata=YpwkTlmVVziJiXkXkD3R8mxDxPJPNn5CGm%2BHMz%2BSBwE%
>>>> 3D&reserved=0>
>>> 
>>> 
>>> 
>>> 
>>> -- 
>>> Carlos Rovira
>>> 
>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%
>>> 2Fcarlosrovira&data=02%7C01%7C%7C022f804829b540f2b8ea08d5282daf79%7Cfa7b1
>>> b5a7b34438794aed2c178decee1%7C0%7C0%7C636459099045827202&sdata=lvwM%2BmBW
>>> p%2FhvTcq7Vy%2Fi9lVbyiNq%2Btzr25lC2V3whBU%3D&reserved=0
>> 
>