Hey all,
Here is the summary of our meeting earlier today.
Thank you all who joined the call, please correct anything I may have
missed.
To all those who didn't join, if you disagree with anything covered, please
voice your opinion.
Overall Summary
Key points discussed:
-
Elad and Paola w
+1 (non-binding)
On Thu, Dec 3, 2020 at 1:41 PM James Timmins wrote:
> +1 (non-binding)
>
> On Thu, Dec 3, 2020 at 1:35 PM Kaxil Naik wrote:
>
>> +1 (binding)
>>
>> On Thu, Dec 3, 2020 at 5:22 PM Arthur Wiedmer
>> wrote:
>>
>>> +1 (binding)
>>>
>>>
>>>
>>>
>>>
>>> On Thu, Dec 3, 2020 at 6:35
Hello Apache Airflow Community,
This is a call for the vote to release Apache Airflow version 1.10.14.
The release candidate:
https://dist.apache.org/repos/dist/dev/airflow/1.10.14rc1/
*apache-airflow-1.10.14rc1-source.tar.gz* is a source release that comes
with INSTALL instructions.
*apache-air
+1
On Thu, Dec 3, 2020 at 3:23 PM Kaxil Naik wrote:
> +1
>
> On Thu, Dec 3, 2020 at 10:14 PM Deng Xiaodong wrote:
>
>> Yep, it clarifies. I find it important because people may have different
>> interpretations on "*support*" and may lead to confusion later. But this
>> supplementary statement
+1
On Thu, Dec 3, 2020 at 10:14 PM Deng Xiaodong wrote:
> Yep, it clarifies. I find it important because people may have different
> interpretations on "*support*" and may lead to confusion later. But this
> supplementary statement suffices to make it clear.
>
> So +1 from me for this proposal.
Yep, it clarifies. I find it important because people may have different
interpretations on "*support*" and may lead to confusion later. But this
supplementary statement suffices to make it clear.
So +1 from me for this proposal. Thanks for wrapping this up.
XD
On Thu, Dec 3, 2020 at 8:29 PM Ja
+1 (non-binding)
On Thu, Dec 3, 2020 at 1:35 PM Kaxil Naik wrote:
> +1 (binding)
>
> On Thu, Dec 3, 2020 at 5:22 PM Arthur Wiedmer
> wrote:
>
>> +1 (binding)
>>
>>
>>
>>
>>
>> On Thu, Dec 3, 2020 at 6:35 AM Jarek Potiuk
>> wrote:
>>
>>> Following the discussion in
>>> https://github.com/apach
+1 (binding)
On Thu, Dec 3, 2020 at 5:22 PM Arthur Wiedmer
wrote:
> +1 (binding)
>
>
>
>
>
> On Thu, Dec 3, 2020 at 6:35 AM Jarek Potiuk
> wrote:
>
>> Following the discussion in
>> https://github.com/apache/airflow/issues/12744
>>
>> I would like to ask for a lazy consensus to get 4 providers
Good point. I propose that we start supporting new python version in
master, after CI is working. The new python version will be supported in
releases starting from the first major or minor release after that.
I hope it clarifies :).
J.
On Thu, Dec 3, 2020 at 7:51 PM Deng Xiaodong wrote:
> Th
FYI. Seems that there are quite many problems with many projects for the
new PIP.
If you want to avoid frustrations - you better downgrade to 20.2.4 now!.
If you want to follow the discussions, there are few interesting issues
(most of them affecting us as well):
- https://github.com/pypa/pi
Thanks Jarek.
To clarify on the 3rd point: I assume you meant "*We support a new version
of Python after it is officially released, as soon as we manage to make it
work in our CI pipeline and release a new version of Airflow (non-Patch
version) based on this CI setting-up (which might not be immed
Hello everyone,
I am casting a vote for our approach to support Python version:
It is following the discussion:
https://lists.apache.org/thread.html/r57502b89f66689a2e5e061ae28ef2ceb8ba7f5cd921ac34b2f7ebe96%40%3Cdev.airflow.apache.org%3E
The proposal is:
1. We finish support for python versio
+1 (binding)
On Thu, Dec 3, 2020 at 6:35 AM Jarek Potiuk
wrote:
> Following the discussion in https://github.com/apache/airflow/issues/12744
>
> I would like to ask for a lazy consensus to get 4 providers installed
> always when you install airflow:
>
> While they are separated out as provid
Following the discussion in https://github.com/apache/airflow/issues/12744
I would like to ask for a lazy consensus to get 4 providers installed
always when you install airflow:
While they are separated out as providers (and can be downgraded or
upgraded independently, we will make them "required
Some progress on that one:
* The PIP team acknowledged the issue and they work on a fix (but other
issues have higher priority): https://github.com/pypa/pip/issues/9203
* I have an idea (based on comments from oauthlib team) how we can fix it -
stay tuned: https://github.com/oauthlib/oauthlib/issu
> What is wrong with having some code which can be used by multiple users.
There's nothing wrong with it. My main point about XCom backends is that it
is not simply "other storage" than database.
> I think instead of making it perfect on the first try, we can open it up
for the community and let
16 matches
Mail list logo
