[REVOKE][VOTE] Release Airflow 1.10.0

[Bolke de Bruin <bd...@gmail.com>]

FYI,

Revoking the vote to address (mostly) license issues.

Cheers
Bolke

> Begin forwarded message:
> 
> From: Bolke de Bruin <bd...@gmail.com>
> Subject: Re: [VOTE] Release Airflow 1.10.0
> Date: 28 July 2018 at 12:52:28 CEST
> To: general@incubator.apache.org
> 
> Hi Justin,
> 
> Thanks for the feedback. The holiday period seems to make gathering +1s a bit slow. We are going to address the issues you and Sebb mentioned and put it up for a revote at the PMC, which should be relatively quick as they don't consider functional changes. For the potential GPL issue I am going to see if we can set NON_GPL by default from the setup while I will also re-open the legal issue to see if there is a more operations friendly way.
> 
> Cheers
> Bolke
> 
>> On 24 Jul 2018, at 23:23, Justin Mclean <ju...@classsoftware.com> wrote:
>> 
>> HI,
>> 
>>> On the GPL dependency you mentioned. We are not distributing GPL sources, not in source or in binary form. This has never been the case.
>> 
>> Which is fine. There are two issues with GPL (Category X software):
>> - you can’t distribute them [1]
>> - Can you rely on them [2]
>> 
>> It’s [2] that seem to be the issues here. Optional dependancies on Category X are allowed but I’m really not sure in this case that it is truly optional.
>> 
>>> As to our solution (for now). Python packages are often installed site-wide and can be part of the dependencies of other packages. While we maybe could enforce the installation of the non-GPL API it would/could 1) interfere with other packages on the same system that do not set this environment variable explicitly. 2) If any the other packages upgrades without setting this variable it would pull in the GPL API. So we decided that it would be better to educate the user and make it part of the install instructions.
>>> 
>>> We can reconsider, but we cannot solve #1 and #2. Which, in my opinion, would make it more opaque to the users. 
>> 
>> IMO at the very least user should be informed that this is the case  and loudly and possibly with a prompt as part of the build and install process so that they understand that what they are using may not be under the terms of the ALv2 as claimed on the cover.
>> 
>>> Given the current situation is at least improvement over the old situation can you reconsider your -1 for this release and preferably agree with our approach (or maybe have an improvement over it)?
>> 
>> I would suggest you reopen the legal JIRA and describe the current situation (like above) and see if an answer can be found.
>> 
>> Other IPMC member (and you mentors) can vote on this release and if it gets 3 +1’s and more plus ones than -1s then it’s a release. Remember a -1 vote on a release is not a veto.
>> 
>> Thanks,
>> Justin
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>> 
>