Hi,
Anyone is free to make a release at any time - you don't even have to be a
committer (but it's a little easier if you are). Currently I don't see that
people have have enough cycles to be able to get a release out every month.
People can use the Nightly if they urgently need a recent bug fi
I like the way Cyanogenmod works with having "Stable, Release Candidate,
M-series, and Nightlies" [1]. Maybe we could setup a quarterly official
release and do an "M-series" style release once a month? The emphasis on
making sure the M release would be working, but would require less scrutiny
;> From: omup...@gmail.com [omup...@gmail.com] on behalf of OmPrakash Muppirala
>> [bigosma...@gmail.com]
>> Sent: Sunday, June 29, 2014 11:08 PM
>> To: dev@flex.apache.org
>> Subject: Re: [DISCUSS] Discuss Release Apache Flex SDK Installer 3.1 - RC3
>>
>> On
it.
>>
>>
> Let us vote on this verification scripts and formalize it, please. We
> don't want to argue this point during every RC.
>
> Thanks,
> Om
>
>
>> -Alex
>> ________
>> From: Justin Mclean [jus...@cla
We
don't want to argue this point during every RC.
Thanks,
Om
> -Alex
>
> From: Justin Mclean [jus...@classsoftware.com]
> Sent: Sunday, June 29, 2014 5:39 PM
> To: dev@flex.apache.org
> Subject: Re: [DISCUSS] Discuss Release Apach
] Discuss Release Apache Flex SDK Installer 3.1 - RC3
Hi,
>> Check out this link. I think it disagrees.
>> http://mail-archives.apache.org/mod_mbox/www-legal-discuss/201405.mbox/%3cCAAS6=7iGt0xW4oBe0sSXC7RzGgDP=kubhgkojzuezbbirq2...@mail.gmail.com%3e
>A little further down it
Hi,
>> Check out this link. I think it disagrees.
>> http://mail-archives.apache.org/mod_mbox/www-legal-discuss/201405.mbox/%3cCAAS6=7iGt0xW4oBe0sSXC7RzGgDP=kubhgkojzuezbbirq2...@mail.gmail.com%3e
A little further down it also says that release candidates are "packages are
intended for develop
during every RC.
Thanks,
Om
> -Alex
>
> From: Justin Mclean [jus...@classsoftware.com]
> Sent: Sunday, June 29, 2014 5:39 PM
> To: dev@flex.apache.org
> Subject: Re: [DISCUSS] Discuss Release Apache Flex SDK Installer 3.1 - RC3
>
> HI,
Hi,
> Check out this link. I think it disagrees.
> http://mail-archives.apache.org/mod_mbox/www-legal-discuss/201405.mbox/%3cCAAS6=7iGt0xW4oBe0sSXC7RzGgDP=kubhgkojzuezbbirq2...@mail.gmail.com%3e
This is basically from [1] and that it is referring to links from our web site,
I think in this cas
: [DISCUSS] Discuss Release Apache Flex SDK Installer 3.1 - RC3
Boy, I wish they'd just call it 14.1.
Here's the score card, for those interested. First, here is the current
entry in sdk-installer-config-4.0.xml:
http://la
From: Erik de Bruin [e...@ixsoftware.nl]
Sent: Sunday, June 29, 2014 10:57 AM
To: dev@flex.apache.org
Subject: Re: [DISCUSS] Discuss Release Apache Flex SDK Installer 3.1 - RC3
>Also, I suggest that we keep to the actual voting rules: when 72 hrs p
From: Justin Mclean [jus...@classsoftware.com]
Sent: Sunday, June 29, 2014 5:30 PM
To: dev@flex.apache.org
Subject: Re: [DISCUSS] Discuss Release Apache Flex SDK Installer 3.1 - RC3
Hi,
>>> 2) A slower release candidate cycle would help, IMO y
Flex SDK Installer 3.1 - RC3
HI,
> The approval scripts attempt to get you to vote with less hassle.
Again to make clear a script is in no way a replacement for voting. Don't get
me wrong it's very useful as a basic check and hopefully that will mean people
will vote more. But pu
HI,
> The approval scripts attempt to get you to vote with less hassle.
Again to make clear a script is in no way a replacement for voting. Don't get
me wrong it's very useful as a basic check and hopefully that will mean people
will vote more. But put it this way, running the script 1000 tim
Hi,
>> 2) A slower release candidate cycle would help, IMO you'll get more
>> reviews, more testing and less release candidates overall.
> Fewer releases per year doesn't sound helpful to the community.
release candidate != release I'm talking about how often RCs are produced in a
single release
>
> >OK, that's nice and all, but let's get into specifics. What do you suggest
> >we do to simplify and speed up the release process of the separate
> >projects?
> The approval scripts attempt to get you to vote with less hassle. There
> could be more improvements in the scripts to show diffs in
On 6/29/14 9:10 AM, "Erik de Bruin" wrote:
>>
>> something that's missing. We are not allowed to use nightly builds as a
>> rapid release mechanism.
>>
>
>That is silly. I think we should beat the lawyers at their own game and
>just refrain from calling the nightlies "releases" and proceed to
>
> something that's missing. We are not allowed to use nightly builds as a
> rapid release mechanism.
>
That is silly. I think we should beat the lawyers at their own game and
just refrain from calling the nightlies "releases" and proceed to make them
the way early adopters meet FlexJS.
The re
On 6/29/14 8:27 AM, "Erik de Bruin" wrote:
>>
>> the community. We need to make this process simpler and faster. We're
>> going to have six releases once we start shipping BlazeDS.
>>
>
>What are the pros and cons of having one monolithic "Apache Flex All"
>release 4 times a year. All subproj
>
> the community. We need to make this process simpler and faster. We're
> going to have six releases once we start shipping BlazeDS.
>
What are the pros and cons of having one monolithic "Apache Flex All"
release 4 times a year. All subprojects depend on one another anyway, why
not aim for inc
On 6/29/14 7:29 AM, "Justin Mclean" wrote:
>Hi,
>
>> And then, if your answer is yes, as a release manager, I would request a
>> couple of things.
>
>And in return I also like to request a few things:
>
>1) The RM shouldn't assume everyone can do this as a full time job
What gave you that impre
Hi,
> And then, if your answer is yes, as a release manager, I would request a
> couple of things.
And in return I also like to request a few things:
1) The RM shouldn't assume everyone can do this as a full time job, reviewing
release properly is difficult and sometime the issues are not easy
I'm not saying the update isn't important, I'm saying the differences to
the APIs and even player internals (if any) are too small to particularly
matter from a Flex dev's point of view.
EdB
On Sun, Jun 29, 2014 at 11:01 AM, Justin Mclean
wrote:
> Hi,
>
> > The differences between 14 and 14b
Hi,
> The differences between 14 and 14b are probably too small to matter.
I believe it include updated OpenSSL libs that are not effected by heart bleed
- that's probably important even if it's only perception. I think I saw some
Android apps were being rejected because of using the wrong vers
On Sun, Jun 29, 2014 at 12:01 AM, Erik de Bruin wrote:
> The differences between 14 and 14b are probably too small to matter. I
> wouldn't worry too much and don't offer beta installs if they are on the
> same version. Just re-activate the beta installs when they start the 15
> cycle, and stop it
The differences between 14 and 14b are probably too small to matter. I
wouldn't worry too much and don't offer beta installs if they are on the
same version. Just re-activate the beta installs when they start the 15
cycle, and stop it again once there is a 15 release.
EdB
On Sun, Jun 29, 2014
Boy, I wish they'd just call it 14.1.
Here's the score card, for those interested. First, here is the current
entry in sdk-installer-config-4.0.xml:
http://labsdownload.adobe.com
pub/labs/flashruntimes/air/
Hi,
> I switched the beta version to 14.0b and that
> got the url lookup and cache to work for me, but then we get messed up at
> the end of the install script trying to stick 14.0b into the
> flex-sdk-description and/or flex-config.
Remove alpha's from version numbers before substituting?
Re
Well, that seems to fix the caching and lookup problem, but there remains
an interesting issue: right now we really don't have code in the install
scripts and/or installer that handle having both a released AIR 14 and an
AIR 14 (beta). The install scripts need a distinct version number in
order to
Finally found time to respond to this (while waiting for AIR 14 beta SDK
to download)
On 6/27/14 3:50 AM, "DarkStone" wrote:
>Hi folks,
>
>Could I have my humble suggestions:
>
>1. Alex is doing so much things, we can see he is very busy these days.
>So about the Legal Issues, can Apache assign
On 6/27/14 12:23 AM, "Justin Mclean" wrote:
>Hi,
>
>So we are fine with being inconstant here?
>
>For instance for Flex Unit we have copyright in LICENSE:
>
> Some of the code in the directories FlexUnit4UIListener and
> FlexUnit4CIListener of FLexUnit is based on Flex Unit 1. This code is
>
Hi folks,
Could I have my humble suggestions:
1. Alex is doing so much things, we can see he is very busy these days. So
about the Legal Issues, can Apache assign someone specifically to do the Legal
works (Licence & Notice etc.), instead of having Alex to do it.
2. I like the attitude of Just
I've said about all I can without repeating myself. It seems I'm not alone
in wishing to move on, and that's what I'm going to do.
Thanks,
EdB
P.S. If you could stop implying (in public) that I don't take my
responsibilities as PMC member seriously, that would be lovely.
On Fri, Jun 27, 2014
Hi,
> Wow. On an Open Source project dedicated to developing a cross platform
> programming framework you consider the minutiae of an otherwise correct
> attribution of a downstream artefact MORE IMPORTANT than the maintenance
> and development work on that project?
It is just as important IMO, w
+1
Von: Erik de Bruin
Gesendet: Freitag, 27. Juni 2014 09:53
An: dev@flex.apache.org
Betreff: Re: [DISCUSS] Discuss Release Apache Flex SDK Installer 3.1 - RC3
>
> The contents NOTICE and LICENSE are probably the most import thing
> cert
>
> The contents NOTICE and LICENSE are probably the most import thing
> certainly not inconsequential as you suggest. As I PMC member I have a
> responsibility to ensure that they are correct - as do all other PMC
> members.
>
Wow. On an Open Source project dedicated to developing a cross platfor
Hi,
> This micromanaging of a tiny inconsequential detail in a file no one ever
> reads is really beyond
> ridiculous.
The contents NOTICE and LICENSE are probably the most import thing certainly
not inconsequential as you suggest. As I PMC member I have a responsibility to
ensure that they ar
I only wish you would spend the time this discussion is taking on fixing
the SDK or adding new features to it. This micromanaging of a tiny
inconsequential detail in a file no one ever reads is really beyond
ridiculous.
You are a committer, change the text to whatever you think is best. Don't
expe
HI,
> Justin, please? You got your way (#2) and we have met and exceeded the
> obligations as per even the hardliner opinion on legal-discuss.
This is not the case please read the full thread on legal discuss.
Justin
Hi,
> How about we just download the fonts during the build and not include it in
> the source kit?
I'd prefer we didn't do that - more download means more that can go wrong, URLs
can change, not work etc etc
Justin
Hi,
So we are fine with being inconstant here?
For instance for Flex Unit we have copyright in LICENSE:
Some of the code in the directories FlexUnit4UIListener and
FlexUnit4CIListener of FLexUnit is based on Flex Unit 1. This code is
licensed under the BSD 3-clause license and copyright (c
How about we just download the fonts during the build and not include it in
the source kit?
Thanks,
Om
On Jun 26, 2014 11:35 PM, "Erik de Bruin" wrote:
> Justin, please? You got your way (#2) and we have met and exceeded the
> obligations as per even the hardliner opinion on legal-discuss. This
Justin, please? You got your way (#2) and we have met and exceeded the
obligations as per even the hardliner opinion on legal-discuss. This is
getting ridiculous and we need to move on!
EdB
On Fri, Jun 27, 2014 at 7:59 AM, Justin Mclean
wrote:
> Hi,
>
> As I said many time Google do want att
On 6/26/14 10:59 PM, "Justin Mclean" wrote:
>Hi,
>
>As I said many time Google do want attribution and this was why I raised
>the issue in the first place.
>
>See https://www.google.com/fonts/attribution for required attributions.
Please feel free to continue the discussion on legal-discuss. I
Hi,
As I said many time Google do want attribution and this was why I raised the
issue in the first place.
See https://www.google.com/fonts/attribution for required attributions.
Justin
On 6/26/14 6:51 PM, "Justin Mclean" wrote:
>Hi,
>
>The amended text is still missing the copyright owner. Normally for
>source code this wouldn't be needed as the copyright owner is included in
>plain text in the code header, however in this case we are bundling a
>binary font where the copyrig
Hi,
The amended text is still missing the copyright owner. Normally for source code
this wouldn't be needed as the copyright owner is included in plain text in the
code header, however in this case we are bundling a binary font where the
copyright owner is not immediately obvious.
Thanks,
Just
Actually, full text of the change not LICENSE (borrowing from the HTTPD
wording)
APACHE FLEX SUBCOMPONENTS:
The Apache Flex Installer includes a number of subcomponents with
separate copyright notices and license terms. Your use of the source
code for the these subcomponents is subject t
Turns out this morning I heard from the hard-liner I was most concerned
about on legal-discuss. To my surprise, he also recommended #2 and
supported changing the documentation. So I've added the following to the
installer license:
The Open-Sans font is available under Apache License 2.0. For de
I'd go with option 1, as I think Alex's arguments are based on the text and
spirit of Apache's own documentation and legal advise, but since that would
keep this endless (and as it turns out unnecessary) discussion alive, I
suggest we go with option 2. Justin obviously won't give up on this, nor
wi
This crossed paths with my other reply. I do not think we should go with
#2, but if you and Justin feel this is the right thing to do, then that's
what we'll do. I'm out of time for tonight, but will start on prepping
Rcs with #2 tomorrow.
-Alex
On 6/25/14 11:32 PM, "OmPrakash Muppirala" wrote
On 6/25/14 11:27 PM, "Justin Mclean" wrote:
>Hi,
>
>> I do not believe the legal-discuss folks agree that there is a legal
>> requirement, otherwise they would require us to change LICENSE and
>>NOTICE
>> which they have not.
>
>Which is why the advice was to add it to the LICENSE file. While i
Alex, if you don't have an objection to #2, let's go with that?
Thanks,
Om
On Jun 25, 2014 11:16 PM, "Alex Harui" wrote:
>
>
> On 6/25/14 11:07 PM, "Justin Mclean" wrote:
>
> >Hi,
> >
> >+1 for 2 as :
> >- that's easy to do
> >- complies with legal requirements re acknowledging copyright (which
Hi,
> I do not believe the legal-discuss folks agree that there is a legal
> requirement, otherwise they would require us to change LICENSE and NOTICE
> which they have not.
Which is why the advice was to add it to the LICENSE file. While it's not
mandated by the Apache license, it may be a lega
On 6/25/14 11:07 PM, "Justin Mclean" wrote:
>Hi,
>
>+1 for 2 as :
>- that's easy to do
>- complies with legal requirements re acknowledging copyright (which are
>in addition to the license terms in some locations)
I do not believe the legal-discuss folks agree that there is a legal
requirement,
Hi,
+1 for 2 as :
- that's easy to do
- complies with legal requirements re acknowledging copyright (which are in
addition to the license terms in some locations)
- is in an obvious place for users to see
- there is precedence in other projects
Justin
Returning to this topic after consulting legal-discuss.
The main person who usually responds to me says that we don't have to
modify LICENSE or NOTICE for the Google Fonts. However, he did say that
he has seen other projects modify LICENSE for bundled non-text
dependencies and thinks it is up to
So what do you propose and what quotes support it?
Sent via the PANTECH Discover, an AT&T 4G LTE smartphone.
Justin Mclean wrote:
Hi
> But just so I understand: is your position now that the LICENSE and NOTICE
> are ok as-is?
No as I've said several time we need to acknowledge Google's copyri
Hi
> But just so I understand: is your position now that the LICENSE and NOTICE
> are ok as-is?
No as I've said several time we need to acknowledge Google's copyright in a
clear way - hiding it a binary file doesn't make it clear where it is from
for any one looking at the code.
If something goe
I'm going to ask on legal-discuss. I've commented in-line as well.
IMO, nothing you quoted here contradicts this passage which is from the
legal folder:
http://www.apache.org/legal/src-headers.html
"If the media comes from a third-party source (not contributed directly to
the project), then any c
Hi,
> Agreed. Any argument to put copyright attribution anywhere is essentially
> claiming it to be an uncommon situation, especially since it isn't called
> out in [1].
Well actually it is, AL is a permissive license. It no different to MIT or BSD
in that regard, the only difference being is
On 6/20/14 4:45 PM, "Justin Mclean" wrote:
>HI,
>
>> Correct. I know you are busy but I hoped you would carefully read the
>> entire quote.
>I did - see my email.
OK, well you confused me by quoting a passage that had no bearing on the
discussion.
>
>> And I believe that is the reason to inclu
On 6/20/14 4:30 PM, "Justin Mclean" wrote:
>Hi,
>
>> If the media comes from a third-party source (not contributed directly
>>to
>> the project), then any copyright notice that is obviously associated
>>with
>> the media should be copied into the NOTICE file."
>
>This is the case however it is
HI,
> Correct. I know you are busy but I hoped you would carefully read the
> entire quote.
I did - see my email.
> And I believe that is the reason to include in NOTICE
Again I don't believe this to be the case. You may want to read 4 (d) of the
AL for the consequences of adding stuff to the
Hi,
> If the media comes from a third-party source (not contributed directly to
> the project), then any copyright notice that is obviously associated with
> the media should be copied into the NOTICE file."
This is the case however it is a permissive licence so should not go in the
NOTICE file.
On 6/20/14 4:21 PM, "Justin Mclean" wrote:
>Hi,
>
>> If the media was contributed directly to an ASF project
>This is not the case.
Correct. I know you are busy but I hoped you would carefully read the
entire quote. The second half says:
"If the media comes from a third-party source (not con
The next line Alex quoted says:
If the media comes from a third-party source (not contributed directly to
> the project), then any copyright notice that is obviously associated with
> the media should be copied into the NOTICE file.
>
The copyright notice needs to be added to the NOTICE, right?
Hi,
> If the media was contributed directly to an ASF project
This is not the case.
Justin
OK. I could not reproduce Piotr's issue, but I can see one way he might
have gotten into that trap, so I am adding a null check for that and
Google copyright to NOTICE and creating RC4. Votes will carry over.
-Alex
On 6/20/14 11:12 AM, "OmPrakash Muppirala" wrote:
>On Fri, Jun 20, 2014 at 10:
On Fri, Jun 20, 2014 at 10:51 AM, Justin Mclean
wrote:
> Hi,
>
> > As I said earlier, this issue was resolved during the Incubation release
> of
> > the Installer. I would say we are good with things as it is.
>
> I disagree - we are not abiding by the terms of their license and it's
> difficult
I will repeat the statements I made earlier.
The proposal is to put the Google Copyright, not a License of any sort, in
the NOTICE file based on this excerpt from this link:
http://www.apache.org/legal/src-headers.html
"Do images or other media require a copyright line in the NOTICE file?If
the me
Hi,
> OK, will look into it. While we're on the subject of the installer, does
> anybody have any more input on putting the Google Copyright in the NOTICE
> (not LICENSE)?
Why NOTICE? Everything I've read says that compatible licences do not go in
NOTCE. NOTICE is a lot stronger than LICENSE an
Hi,
> As I said earlier, this issue was resolved during the Incubation release of
> the Installer. I would say we are good with things as it is.
I disagree - we are not abiding by the terms of their license and it's
difficult to a user or reviewer to know where those files come from without
sp
On Jun 20, 2014 6:48 AM, "Alex Harui" wrote:
>
> OK, will look into it. While we're on the subject of the installer, does
> anybody have any more input on putting the Google Copyright in the NOTICE
> (not LICENSE)?
As I said earlier, this issue was resolved during the Incubation release of
the I
OK, will look into it. While we're on the subject of the installer, does
anybody have any more input on putting the Google Copyright in the NOTICE
(not LICENSE)?
-Alex
On 6/20/14 1:12 AM, "piotrz" wrote:
>Hi Alex,
>
>Just tried to install FlexJS Nightly and got Installation Aborted.
>
>http://
Hi Alex,
Just tried to install FlexJS Nightly and got Installation Aborted.
http://images.devs-on.net/Image/XT26TCGDd5R3DLyH-Obszar.png
Additionally weird thing has happened when I tried to Copy Log it doesn't
work. Every time when I click "Copy Log" it is add block of text with
information bel
On 6/13/14 2:36 PM, "Justin Mclean" wrote:
>Hi,
>
>> Did you actually try it? In what ways does it violates the policy?
>
>Alex you know very well in how it violates the policy (there's been
>discussion elsewhere on this) - releases must be manually checked. Again
>that's not to say it's not u
On Fri, Jun 13, 2014 at 2:36 PM, Justin Mclean
wrote:
> Hi,
>
> > Did you actually try it? In what ways does it violates the policy?
>
> Alex you know very well in how it violates the policy (there's been
> discussion elsewhere on this) - releases must be manually checked. Again
> that's not to
Hi,
> Did you actually try it? In what ways does it violates the policy?
Alex you know very well in how it violates the policy (there's been discussion
elsewhere on this) - releases must be manually checked. Again that's not to say
it's not useful but for a valid votes people need follow the c
Did you actually try it? In what ways does it violates the policy?
On 6/13/14 2:10 PM, "Justin Mclean" wrote:
>Hi,
>
>The automated approach while helpful as a double check is probably
>against current Apace policy on voting on releases. Please follow the
>standard voting procedure.
>
>Thanks,
Hi,
The automated approach while helpful as a double check is probably against
current Apace policy on voting on releases. Please follow the standard voting
procedure.
Thanks,
Justin
This is the discussion thread.
In case you didn't read the full vote thread:
To encourage voting, I have added an Ant script to the RC folder. This ant
script attempts to automate the checks a voter should perform on the RC.
It will:
- download the default source package for your OS (use -Dpack
82 matches
Mail list logo
