royale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Fisher <dave2w...@comcast.net>
Subject Re: Release Philosophy (was Re: [Website] Getting content ready to publish)
Date Fri, 10 Nov 2017 18:47:16 GMT
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
> (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" <harbs.lists@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 <carlosrovira@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 <justin@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
>> 
> 


Mime
View raw message