Re: [DISCUSS] Guidelines for Releasing Providers packages

I have also created a PR for adding documentation for all project-related guidelines: https://github.com/apache/airflow/pull/14674/ -- happy to hear everyone's thoughts. Regards, Kaxil On Mon, Mar 8, 2021 at 10:43 PM Kaxil Naik wrote: > Personally, I agree with *Batch vs Ad-hoc, **Frequency *an

Cancelling Dev Calls

Hi all, We started with regular Dev calls to release Airflow 2.0 last year and had our first call on 10 Aug 2020 for planning and scoping 2.0 features. Since the main aim of releasing 2.0 has been achieved, we will be cancelling the Dev calls. If anyone has items for discussion, please create a [

Re: [DISCUSS] Major Version should contain new features or just removal of deprecation?

I personally would vote for *(b) Contain new features as well as the removal of deprecated features *as otherwise, it does not feel like it is a major release to me. A major release to me is where we add new features of significant values as we did with Airflow 2.0.0. This is also good in terms of

[DISCUSS] Major Version should contain new features or just removal of deprecation?

Hi all, As part of documenting all the guidelines including (PR here ) but not limited to Release, I would like to start the discussion on one of the things that was recently discussed: *What should the major version like 3.0.0 / 4.0.0 contain?* a) On

Re: [VOTE] Airflow Providers - release prepared 2021-03-08

+1 (binding) Verified License, signatures and checksums. Checked changelogs for all the providers -- looks reasonable. Regards, Kaxil On Mon, Mar 8, 2021 at 8:13 PM Jarek Potiuk wrote: > I also created issue where I track the test progress by the contributors > who provided the fixes: https:

Re: [DISCUSS] Guidelines for Releasing Providers packages

Personally, I agree with *Batch vs Ad-hoc, **Frequency *and *Doc-only changes*. For testing, I agree that not all changes need strict testing, "best-effort" and judgement is fine enough for providers because of the low-risk nature of them. For voting, I think separating the VOTE emails can avoid

[DISCUSS] Guidelines for Releasing Providers packages

Hi all, I would like to open the release process of providers up for discussion. Testing and Voting needs more discussion, the other points are mostly straight-forward and had an agreement on the last dev call. (Backport Providers won't be released after the end of this month - link

[Meeting Notes] Airflow Dev Call - 3 March 2021

Hi all, Here are the notes from our Airflow dev call last week. Thank you to all who joined the call. Here is a quick summary of the call. *Summary Notes*: - *Add a policy document around all our Policies / rules in the Github Repo itself* - This should cover any decision we take as

[VOTE] Airflow Backport Providers 2021.3.13rc1

Hey all, I have cut Airflow Backport Providers 2021.3.13rc1. This email is calling a vote on the release, which will last for 72 hours - which means that it will end on Thu 11 Mar 21:54:33 CET 2021. This release contains providers that were skipped in the release from last week due to bugs found/

Re: [VOTE] Airflow Providers - release prepared 2021-03-08

I also created issue where I track the test progress by the contributors who provided the fixes: https://github.com/apache/airflow/issues/14670 On Mon, Mar 8, 2021 at 9:04 PM Jarek Potiuk wrote: > Hey all, > > I have just cut the new wave Airflow Providers packages. This email is > calling a vo

[VOTE] Airflow Providers - release prepared 2021-03-08

Hey all, I have just cut the new wave Airflow Providers packages. This email is calling a vote on the release, which will last for 72 hours - which means that it will end on Thu 11 Mar 20:57:45 CET 2021. This release contains for providers (rc2) that were skipped in the release from last week due

Re: [DISCUSS] TaskGroup in Tree View

I agree, but we should see what of those we can implement just on the parsing side - i.e. can we continue to make the scheduler not have to care about Task Groups? If so, then things like the default args example is a small enough change that it doesn't need an AIP (IMO) -ash On 8 March 2021

Re: [DISCUSS] TaskGroup in Tree View

I personally think that TaskGroup should go beyond being “just” a UI concept. I think that there are a lot of use-cases where people might want to perform a single operation across an entire group of tasks. I think that Bin points out a few really good examples (default arguments and group delet

[discuss] Remove "demo mode" feature?

Prompted by a desire to refactor this feature's related code I kept encountering, I discovered that the feature had been largely broken for some time, so I went ahead and fixed it and refactored in PR #14595 . After some discussion in that PR and learni

Re: [VOTE] AIP-38: Modern Web Application

Voting is now closed, and I am happy to report that AIP-38 has been accepted with unanimous support of 24 (15 binding) “+1” votes! We’ll begin incorporating some foundations into the apache/airflow repo soon, and will be sending details to the Dev list this week for an initial UI SIG meeting. As w

Re: [DISCUSS] TaskGroup in Tree View

Hi, all, it's really exciting to see the great discussions about TaskGroup. There are some interesting ideas here. - Tree View support for TaskGroup: I think this can mostly be achieved at the web layer? Changes probably involve tree.html and www/view.py. Should we change Tree View to organize tas

Dear TEAM, connect to Airflow with Azure SDK (Azure Storage Gen2)

Dear Team. I am trying to connect to the Airflow with Azure Storage Gen2 using the package below. https://pypi.org/project/apache-airflow-providers-microsoft-azure/ I checked through the document that Azure Blob and Azure Storage Gen1 are connected. However, Azure Storage Gen2 cannot see the SD