CANCELED: [VOTE] Release Airflow 2.0.0 from 2.0.0rc1

I'm cancelling this vote -- it doesn't feel right to change what we are voting on mid-vote. And doing it now we can do it as a three day vote, so we only loose one day. New vote for 2.0.0rc2 to follow shortly On Sat, 12 Dec, 2020 at 12:25, Jarek Potiuk wrote: Ah cool. So I think we can dr

Re: [VOTE] Release Airflow 2.0.0 from 2.0.0rc1

Ah cool. So I think we can drop sdist indeed :). I think if it is the only problem found till Monday, I would be OK in dropping sdist from 2.0.0 release then - if this is going to slow down the process by a week. I am happy to change my vote if others are happy with it. Regardless, I updated our

Re: [VOTE] Release Airflow 2.0.0 from 2.0.0rc1

The BigQuery dataset PyPi publishes has a file.type column: Since we started publishing wheels (1.10.3) the wheel almost all of the downloads. This 2020-12-01 (picked randomly): 1.10.12bdist_wheel108311.10.12sdist121.10.1

Re: [VOTE] Release Airflow 2.0.0 from 2.0.0rc1

Update: not provider packages, but the packages that airflow depends on. indeed all our provider/airflow package are pure python and as long as there are no "special cases" like anyone requiring source packages (for whatever reason) they *should* work. On Sat, Dec 12, 2020 at 10:48 AM Jarek Potiuk

Re: [VOTE] Release Airflow 2.0.0 from 2.0.0rc1

It might well be, yes, that we have no such problem in the airflow package. I referred more to the provider packages. I think it would like to hear from the user why sdist was used in this case. Also, I believe there are some distros Gentoo, that always use sources for everything it can (and I am n

Re: [VOTE] Release Airflow 2.0.0 from 2.0.0rc1

On Sat, 12 Dec, 2020 at 10:34, Jarek Potiuk wrote: So I think there will be systems where sdist is used automatically because the host system is not as close to what we use when build wheels. I think that is only a problem for wheels with binary components,but our wheels are not -- they are

Re: [VOTE] Release Airflow 2.0.0 from 2.0.0rc1

Specifically we are not using "manylinux or manylinux2" wheels which are specifically targeting this problem: https://github.com/pypa/manylinux On Sat, Dec 12, 2020 at 10:34 AM Ash Berlin-Taylor wrote: > (After 2.0.0, for now we'll release rc2 with the same set) > > On Sat, 12 Dec, 2020 at 09:24

Re: [VOTE] Release Airflow 2.0.0 from 2.0.0rc1

This might be an option. I asked the user what is the reason the installation was done. However I already experienced some problems with .whl files installed on different platforms. This is one of the reasons we are preparing our wheel files inside the CI container based on debian, because when th

Re: [VOTE] Release Airflow 2.0.0 from 2.0.0rc1

(After 2.0.0, for now we'll release rc2 with the same set) On Sat, 12 Dec, 2020 at 09:24, Ash Berlin-Taylor wrote: I wonder if we should not bother releasing the sdist at all? Since our wheel is OS agnostic anyway, and wheel is much faster to install, I see little point in continuing to releas

Re: [VOTE] Release Airflow 2.0.0 from 2.0.0rc1

I wonder if we should not bother releasing the sdist at all? Since our wheel is OS agnostic anyway, and wheel is much faster to install, I see little point in continuing to release the sdist. We should have the artefacts become the source (`git archive`) and the `wheel` only I think. -ash O

Re: [VOTE] Release Airflow 2.0.0 from 2.0.0rc1

Unfortunately, -1 from me. Here is the issue: https://github.com/apache/airflow/issues/13027 We miss a schema file in sdist package. That causes airflow commands to fail if Airflow is installed using sdist package (.tar.gz) rather than .whl. We've tested everything with .whl files installation a

Re: [VOTE] Release Airflow 2.0.0 from 2.0.0rc1

> > Also inexplicitly got error `scheduler error (sqlite3.OperationalError) > database is locked`. sorry: inexplicably 🤦‍♂️ >

Re: [VOTE] Release Airflow 2.0.0 from 2.0.0rc1

Also inexplicitly got error `scheduler error (sqlite3.OperationalError) database is locked`. Resulting from query DELETE FROM dag_code WHERE dag_code.fileloc_hash NOT IN (?) AND dag_code.fileloc NOT IN (?) Filed here https://github.com/apache/airflow/issues/12999 Possibly related to https://git

Re: [VOTE] Release Airflow 2.0.0 from 2.0.0rc1

After letting a test dag run for a while, after a few successful dag runs, a task run failed with message `sudo: a password is required` Error documented in issue https://github.com/apache/airflow/issues/12997

Re: [VOTE] Release Airflow 2.0.0 from 2.0.0rc1

Since we have all providers in PyPI as well, we rebuilt the images now using a new procedure. All the packages in the "reference" production images are taken from PyPI now and they show the right rc* versions. Have fun :). airflow@d88cc6f8dcc9:/opt/airflow$ airflow version 2.0.0rc1 airflow@d88cc6

Re: [VOTE] Release Airflow 2.0.0 from 2.0.0rc1

An enthusiastic (non-binding) +1 from me! On Wed, Dec 9, 2020 at 11:58 AM Ash Berlin-Taylor wrote: > Hi my lovely Airflowers, > > I have cut Airflow 2.0.0 RC1. This email is calling a vote on the release, > which will run for five days, until 2020-12-14T17:00:00Z > https://www.timeanddate.com/wo

Re: [VOTE] Release Airflow 2.0.0 from 2.0.0rc1

A big thank you to the release team that has been working so hard, the Airflow PMC, the active committers, and the hundreds of contributors who are making Apache Airflow 2.0 a reality. It will be a great foundation for Airflow's continued success. It's a strong, yet non-binding +1 from me! -Ry

Re: [VOTE] Release Airflow 2.0.0 from 2.0.0rc1

A big (non-binding) +1 from me! Nathan From: Ash Berlin-Taylor Date: Wednesday, 9 December 2020 at 16:58 To: dev@airflow.apache.org Subject: [VOTE] Release Airflow 2.0.0 from 2.0.0rc1 Hi my lovely Airflowers, I have cut Airflow 2.0.0 RC1. This email is calling a vote on the release, which

Re: [VOTE] Release Airflow 2.0.0 from 2.0.0rc1

(non-binding) +1! On Thu, Dec 10, 2020 at 1:24 AM James Timmins wrote: > An emphatic (non-binding) +1 !!! > > On Wed, Dec 9, 2020 at 8:58 AM Ash Berlin-Taylor wrote: > >> Hi my lovely Airflowers, >> >> I have cut Airflow 2.0.0 RC1. This email is calling a vote on the >> release, which will run

Re: [VOTE] Release Airflow 2.0.0 from 2.0.0rc1

An emphatic (non-binding) +1 !!! On Wed, Dec 9, 2020 at 8:58 AM Ash Berlin-Taylor wrote: > Hi my lovely Airflowers, > > I have cut Airflow 2.0.0 RC1. This email is calling a vote on the release, > which will run for five days, until 2020-12-14T17:00:00Z > https://www.timeanddate.com/worldclock/f

Re: [VOTE] Release Airflow 2.0.0 from 2.0.0rc1

Ash is going to also release providers rc1 soon, but for those who would like to test using Docker images. 2.0.0rc1 images are ready with a subset of providers baked in: docker run -it apache/airflow:2.0.0rc1-python3.6 bash airflow@a4726a32f5f3:/opt/airflow$ airflow version 2.0.0 airflow@a4726a32f

[VOTE] Release Airflow 2.0.0 from 2.0.0rc1

Hi my lovely Airflowers, I have cut Airflow 2.0.0 RC1. This email is calling a vote on the release, which will run for five days, until 2020-12-14T17:00:00Z (or until 3 +1 binding votes have been recieved)