Hi, I agree with this, but want to expose some thoughts that I consider important:
I think we must to cut a release as we get in the same similar stable state as we had in FlexJS (0.8.0), and call it 0.8.0, since this is only a transition release to get in our new house, but we still have some missing key pieces to get 0.9.0 and 1.0 I suppose a Alex talks about "some years" but I don't think so. If we do 0.9 and 1.0 in the right way, I expect to make huge noise on the internet talking about Apache Royale and making lots of people put an eye on us. This must be at proper time to get people reaching to us not leave easily and take us seriously as a real alternative. How many time to get this? I hope more soon than later. Maybe 1T 2018? 2T? People coming at that time will start to use Royale and we will need some coherence all around. That's crucial and that will make us not easy to make certain changes that could make user developments not valid. So, for example, We still does not have a clear list of starter UI components and controls. I think we will need to discuss that and work for it so people could rely on some quality components (I think I will create a thread about this concrete part since I think is crucial for us). We will need to have certain parts of Royale very robust and defined so people could come and expect and easy relation with that parts and avoid to left because they think we "many things" but as well "many of that things are not finished" in a quality level similar to the quality level reached on apache flex. So, going back. We need to cut a release as soon as we can to get a valid starter point, we need to release the new website with quality content and what we could have soon (if we have royale on NPM, that's good!, and so on....), we can put a download page with releases and talk about ways for people to get nightly builds, but we must think in the people that will come to us and what they expect to see; For me: something clear, as easy as possible info in website, an sdk with proven valid ways to make apps and a concrete set of UI controls and components that works really well to start building the same day they know about Apache Royale. 2017-11-10 20:12 GMT+01:00 Dave Fisher <dave2w...@comcast.net>: > Hi - > > I agree it is intent and trust. A couple of incidents in the long history > of POI. > > (1) we discovered a GPL file that had been in the source tree for a couple > of releases and removed it. > > (2) we had a complaint from the copyright holder that a test file belonged > to him. It had been there for many years. We removed it from the next > release. > > Anyone concerned with nit picking this should be watching every commit. In > the Incubator a mentor will bring it up then and most often say next time. > Here in a project we deal as they come and it should be on the commit. > > If someone brings in a significant amount of code then a SGA may be needed > along with IP Clearance in the Incubator. > > Regards, > Dave > > Sent from my iPhone > > > On Nov 10, 2017, at 11:02 AM, Alex Harui <aha...@adobe.com.INVALID> > wrote: > > > > Hi Dave, > > > > It would help to make license problems rare if we also do something else > > Roy has mentioned recently that has to do with trust and intent. If you > > dig hard enough, or take an "untrusting" philosophy that if something > > isn't perfectly documented that someone is going to use that imperfection > > against you or the foundation, you can continue to find small licensing > > issues, especially in the third party artifacts we consume. > > > > Roy basically said that folks want us to use the stuff the make available > > on open source sites otherwise they wouldn't have put it there. They > > might have slightly different rules about sharing it and modifications to > > it, but the intent is to share it. > > > > So let me add to "better and not illegal" with "trust". > > > > Thanks, > > -Alex > > > >> On 11/10/17, 10:47 AM, "Dave Fisher" <dave2w...@comcast.net> wrote: > >> > >> Hi - > >> > >> For source code we can point to github from the website. > >> > >> For nightly builds we can let people know about it on dev@ but should > not > >> link to it from the website. We can explain on the website or wiki that > >> we are doing nightly builds and that they can find out from the dev@ > list. > >> > >> At this point it should be rare to have a license problem in the > >> repository because we all should know the rules or how to ask on dev@ > or > >> private@ first. > >> > >> Clear? > >> > >> Regards, > >> Dave > >> > >> > >> > >> Sent from my iPhone > >> > >>> On Nov 10, 2017, at 10:36 AM, Alex Harui <aha...@adobe.com.INVALID> > >>> wrote: > >>> > >>> Forking this specific issue about nightly builds... > >>> > >>> AIUI, this issue about nightly builds has arisen before with other > >>> projects. I'd have to go through board@/member@ archives but I think > >>> some > >>> projects have found some pretty clever solutions to linking to nightly > >>> builds. > >>> > >>> That said, one of the benefits of creating a Royale project separate > >>> from > >>> Flex is that there should not be any 'competition' in the release > queue. > >>> For example, the Flex project is currently trying to get two releases > >>> out, > >>> and if some other Flex member wanted to rush out a BlazeDS release, > >>> they'd > >>> probably have to wait. > >>> > >>> Royale has 3 main repos, and under FlexJS/Falcon, we created 2 sets of > >>> release artifacts. Royale might still have 2 sets of release artifacts > >>> ( > > -- Carlos Rovira http://about.me/carlosrovira
