I love this! Thanks for doing that!
Have we considered sending the messages to a dedicated alerting channel? E.g.
#internal-airflow-ci-cd-alerts
That way you could set notifications to all messages of that channel, to get a
notification when main is failing, without getting a notification for ev
+1 for Edge, great suggestion, I think that conveys even more specifically the
kind of context AIP-69 executors/workers are running in.
Full votes:
+0.9 Distributed
+0.5 External
-0.5 Agent
-1 Remote
From: Scheffler Jens (XC-AS/EAE-ADA-T)
Sent: Wednesday, Augu
As you'd expect Jens I also vote +1 for distributed :)
Remote as it means today is not only in our docs but in our previous summit
talks, town halls, Github Issues/Discussions, Slack threads, etc. It's a term
we've used as a community for years. So we should not change all that under the
feet o
I don't feel too strongly about this one (I suppose I also lean allow) but I
agree with removing as many of these configs as possible! So I'm all for this
one, either way.
From: Daniel Standish
Sent: Thursday, August 15, 2024 6:13:31 PM
To: dev@airflow.apache.or
Agree with Elad's take on this. I'd say no "large" features, but leaving some
wiggle room for changes that allow an easier segue to Airflow 3 would be great.
From: Amogh Desai
Sent: Tuesday, August 20, 2024 8:53:21 PM
To: dev@airflow.apache.org
Subject: RE: [EXT]
To me I think if we have a trigger rule of run always, then a rule of run never
isn't so unreasonable.
Also regarding just adding the code snippet inline in the docs, rather than
importing from the DAG: The nice thing about having it come from the system
test DAG is that the code snippet stays
+1 (binding)
A lot of effort went into this one, great job Jarek. I'm happy to see this one
get across the line because we hear from so many users and customers who want
this feature. It's important to focus on building what users are asking for.
From: Shahar Ep
+1 (binding)
From: Shahar Epstein
Sent: Wednesday, August 7, 2024 10:59:04 AM
To: dev@airflow.apache.org
Subject: RE: [EXT] [VOTE] AIP-82 - External event driven scheduling in Airflow
CAUTION: This email originated from outside of the organization. Do not click
+1 (binding)
I love any and all AIPs to remove deprecated code in the next major release! ❤
From: Brent Bovenzi
Sent: Thursday, August 1, 2024 7:05:35 AM
To: dev@airflow.apache.org
Subject: RE: [EXT] [VOTE] AIP-83 Remove Execution Date Unique Constraint from
DAG
Hello folks,
This is a short note to announce that the AWS Open Source Credits Program has
approved us for another round of credits this year. $31,000 of credits have
been deposited in our Apache Airflow AWS account as of yesterday!
These credits help to run portions of our hosted testing infra
I have to throw a shamless self-vote in for #40017 which represents the main
chunk (the scheduler changes) for AIP-61 Hybrid Executors (now Multiple
Executor Configuration) 🎉
From: Jarek Potiuk
Sent: Thursday, July 25, 2024 5:12:41 AM
To: dev@airflow.apache.org
+1 (binding)
From: Brent Bovenzi
Sent: Tuesday, July 23, 2024 11:10:47 AM
To: dev@airflow.apache.org
Subject: RE: [EXT] [VOTE] AIP-65: Improve DAG history in UI
CAUTION: This email originated from outside of the organization. Do not click
links or open attachmen
+1 (binding)
From: Shahar Epstein
Sent: Monday, July 22, 2024 10:02:22 AM
To: dev@airflow.apache.org
Subject: RE: [EXT] [VOTE] AIP-66: DAG Bundles and Parsing
CAUTION: This email originated from outside of the organization. Do not click
links or open attachments
Overall I'm +1
NOTE: I still strongly believe we should _not_ brand this "Remote Executors" we
already use Remote Executors (to mean CeleryExecutor, K8sExecutor, etc) in many
many contexts as a contrast to Local Executors (LocalExecutor,
SequentialExecutor). It's in our docs, blog posts, Airflo
+1 binding
As Jarek mentioned, still some discussions ongoing but I think that can be
hashed out later. Looks good overall.
From: Elad Kalif
Sent: Thursday, July 11, 2024 9:11:19 AM
To: dev@airflow.apache.org
Subject: RE: [EXT] [VOTE] AIP-72: Task Execution Inte
+1 binding
From: Jed Cunningham
Sent: Thursday, May 9, 2024 7:59:03 AM
To: dev@airflow.apache.org
Subject: RE: [EXTERNAL] [COURRIEL EXTERNE] [VOTE] Proposal for adding Telemetry
via Scarf
CAUTION: This email originated from outside of the organization. Do not cl
+1 binding
Excited for this one!
From: Aritra Basu
Sent: Thursday, April 18, 2024 7:37:08 AM
To: dev@airflow.apache.org
Subject: RE: [EXTERNAL] [COURRIEL EXTERNE] [VOTE] AIP-67 Multi-team deployment
of Airflow components
CAUTION: This email originated from outs
Congrats Wei! Well deserved :)
From: Scheffler Jens (XC-AS/EAE-ADA-T)
Sent: Monday, April 8, 2024 2:12:41 PM
To: dev@airflow.apache.org
Subject: RE: [EXTERNAL] [COURRIEL EXTERNE] [ANNOUNCE] New committer: Wei Lee
CAUTION: This email originated from outside of the
://www.postgresql.org/docs/current/ddl-rowsecurity.html
Cheers,
Gabe
--
Gabe Schenz
From: Oliveira, Niko
Date: Thursday, March 28, 2024 at 12:38 PM
To: dev@airflow.apache.org
Subject: [EXTERNAL] Re: [DISCUSS] DRAFT AIP-67 Multi-tenant deployment of
Airflow components
This Message originated out
+1I'd love to see this as well.
In the past, stability and long queue times of PR builds have been very
frustrating. I'm not 100% sure this is due to using self hosted runners, since
35 queue depth (to my mind) should be plenty. But something about that setup
has never seemed quite right to me
Hey folks, just some thoughts on the topics below:
1) I'm not too fussed about the naming. There has been many years of us
branding this multitenancy (talks, townhalls, email chains, etc), so a lot of
our users are already familiar with this name. I'm not sure we'll benefit much
by changing it
+1 (binding) Glad this is finally getting some love!
From: Ankit Chaurasia
Sent: Tuesday, March 26, 2024 2:58:13 AM
To: dev@airflow.apache.org
Subject: RE: [EXTERNAL] [COURRIEL EXTERNE] [VOTE] AIP-64: Keep TaskInstance try
history
CAUTION: This email originated
I'm -1 to enabling D105
I don't think it will lead to helpful documentation. I think for the rare cases
it is required it can left up to the developer or caught in PR review.
Cheers,
Niko
From: Vincent Beck
Sent: Wednesday, March 20, 2024 5:51:43 AM
To: dev@ai
Fantastic results!
> It also means that if you've been using breeze and were sometimes afraid to
> hit "y" to rebuild the image, being afraid that it will take 20 minutes or
> so - not any more. It should be WAY faster now.
I'm very excited about this speed up as well as our CI :)
_
The Astral folks also seem very focused on it being a drop-in/compliant
replacement for pip. So I think it's definitely worth dropping it in and seeing
if we get the expected performance improvements. If tests still pass and user
facing constraints and install instructions remain unchanged I don
t's worth), naming channels after personas is the way to go. I also
> think
> > we can consolidate some of these. I think:
> >
> > #dev-support -> from #development
> > #troubleshooting
> > #best-practices
> > #random
> > #first-pr-support -->
I'm not too picky on the names, but I'm +5 to Jed's approach of just archiving
the current development channel and starting fresh with a new channel for
contribution. There no manner of rebranding that we can do to save #development
now, with that many folks in it.
I'll throw #contributors into
Hey folks!
The voting for AIP-61: Hybrid Execution
(https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-61+Hybrid+Execution)
was completed on February 06, 2024 PST, and I am happy announce the following
voting result:
*Binding (+8) Votes*
Jens Scheffler
Jarek Potiuk
Amogh Desai
Dennis Ferr
Hey folks,
The AIP for Hybrid Executors has been out for a few weeks now. Some great
feedback came in and some challenges to scope which I think have all been
addressed, and the AIP document has been updated where applicable.
At this point I'd like to call a vote, and if all goes well, begin
Yeah, I've found this to be pretty smooth as well. In most cases comments were
already resolved and in lesser cases it was useful to see which conversations
still needed addressing before merging. +1 from me!
From: Ryan Hatter
Sent: Tuesday, January 30, 2024 8:5
+1 (binding)
From: Wei Lee
Sent: Sunday, January 21, 2024 5:24:54 PM
To: dev@airflow.apache.org
Subject: RE: [EXTERNAL] [COURRIEL EXTERNE] [VOTE] Accept AIP-60 (Standard URI
representation for Airflow Datasets)
CAUTION: This email originated from outside of the
will provide some debugging challenges when a
task runs on one executor on one attempt, but a different executor on a
different attempt. It might be nice if users could set a
`use_default_executor_on_retry` kind of parameter.
On Mon, Jan 15, 2024 at 1:05 PM Oliveira, Niko
wrote:
> Hey folks!
>
Congrats Andrey!
From: Pankaj Singh
Sent: Monday, January 15, 2024 11:11:01 AM
To: dev@airflow.apache.org
Subject: RE: [EXTERNAL] [COURRIEL EXTERNE] [ANNOUNCE] New PMC member: Andrey
Anshin (taragolis)
CAUTION: This email originated from outside of the organizat
Interesting how 50/50 this one has turned out to be!
I'm personally in favour (+1). The less I have to worry about accidental typos,
indentation, quoting, etc the better, I can focus on important changes. It will
also unblock many PRs from contributors that are otherwise mergeable except for
be
This is fantastic! I love to see the testing and dashboards being invested in
from the beginning, never gets old :)
It shows that you really took the time to read the past discussions and
documentation we have. I won't be able to look at the code in detail until the
new year, but so far this is
Congrats! Very well deserved!
From: Pankaj Koti
Sent: Monday, December 4, 2023 11:28:41 AM
To: dev@airflow.apache.org
Subject: RE: [EXTERNAL] [COURRIEL EXTERNE] [ANNOUNCE] New committer: Utkarsh
Sharma
CAUTION: This email originated from outside of the organizat
I love this idea!
Another option, that I don't think we as a community are very good at, is
putting the context of the change in the git commit message itself. Those
messages are already tightly associated into git history and the code itself
via blame without needing to introduce an new concep
Love this idea!
Jumping on this thread to be able to receive the agenda Briana mentioned (but I
think there's no harm in just including it here for anyone to read).
Cheers,
Niko
From: Briana Okyere
Sent: Wednesday, November 29, 2023 9:30:21 AM
To: dev@airflo
+1
From: Pierre Jeambrun
Sent: Thursday, November 23, 2023 10:28:52 AM
To: dev@airflow.apache.org
Subject: RE: [EXTERNAL] [COURRIEL EXTERNE] [DISCUSS] Suspend/Remove Apache
Scoop provider
CAUTION: This email originated from outside of the organization. Do not cl
If no one comes forward willing to support the executor long term I'm +1 for
removal.
From: Vincent Beck
Sent: Thursday, November 16, 2023 10:59:40 AM
To: dev@airflow.apache.org
Subject: RE: [EXTERNAL] [COURRIEL EXTERNE] [DISCUSS] Suspend (Remove?)
Daskexecutor
Congrats Jens!!
From: Briana Okyere
Sent: Tuesday, November 7, 2023 1:00:35 PM
To: dev@airflow.apache.org
Subject: RE: [EXTERNAL] [COURRIEL EXTERNE] [ANNOUNCE] New committer: Jens
Scheffler
CAUTION: This email originated from outside of the organization. Do not
+1 (binding)
looking forward to having more native LLM capabilities in Airflow!
From: Aritra Basu
Sent: Wednesday, October 25, 2023 12:10:00 PM
To: dev@airflow.apache.org
Subject: RE: [EXTERNAL] [COURRIEL EXTERNE] [VOTE] Add providers for Pinecone,
OpenAI & Cohe
I really like this idea as well! One of the _the most common_ questions I get
from people managing an Airflow env is "Why is my task stuck in state X".
Anything we can do to make that more discoverable and user friendly, especially
in the UI instead of (or in addition to) logs would be fantastic
+1 to this!
I also have a docs section half written on the executor interface and how to
extend it. But I've been very busy with a few other items that are completing
soon.
Cheers,
Niko
From: Pankaj Koti
Sent: Friday, September 8, 2023 12:03:35 PM
To: dev@airf
I'd prefer we stick with semver. As discussed already, there is a little
friction with each approach, and it's who that friction lands on that's
important. If we moved to a more time based breaking change approach then it
reduces our frustration but shifts it over to our users. Whereas right no
I'd vote for a period of time with warnings (either in the logs and/or in the
Airflow UI), as a deprecation warning of sorts. Followed by removing the
feature later on, unless we find that the warnings are enough to lower the
operational load this causes us, but I think that's unlikely.
Cheers,
+1 (binding)
From: Jed Cunningham
Sent: Monday, August 28, 2023 9:32:43 AM
To: dev@airflow.apache.org
Subject: RE: [EXTERNAL] [VOTE] Drop MsSQL as supported backend
CAUTION: This email originated from outside of the organization. Do not click
links or open attac
+1 (non-binding)
Checked my change as well as ran an AWS System test suite on the release
candidate, all green:
https://aws-mwaa.github.io/open-source/system-tests/version/b5a4d36383c4143f46e168b8b7a4ba2dc7c54076_8.5.1rc1.html
Cheers,
Niko
From: Vincent Beck
Tested the RC1 against the Amazon system tests and the results can be viewed
here:
https://aws-mwaa.github.io/open-source/system-tests/version/ddcd30e7c7f5daeab5f74fb3224a4d5e33cec95d_8.4.0rc1.html
I would still like to do some more testing around executors.
P.S.
I think the Celery issue Vikram
Congrats Hussein!
From: Beck, Vincent
Sent: Monday, July 31, 2023 7:32:08 AM
To: dev@airflow.apache.org
Subject: RE: [EXTERNAL] [ANNOUNCE] New PMC member: Hussein Awala
CAUTION: This email originated from outside of the organization. Do not click
links or open a
Looking forward to this one! I think the new behaviours will be much better
than we have now.
+1 (binding)
From: Utkarsh Sharma
Sent: Thursday, July 20, 2023 11:45:57 PM
To: dev@airflow.apache.org
Subject: RE: [EXTERNAL][VOTE] AIP-57 Refactor SLA Feature
CAUT
As I've said before I believe not pre-installing celery and k8s executors
should be the ultimate goal, so I totally agree with this, but we need to do it
in a way that minimizes impact. It's hard to catch every angle possible with
these sorts of things (i.e. Daniel's point of folks installing re
I agree with Jed. I don't actually mind allowing contribution of any
config/section but I think any conflicts discovered should fail very loudly.
From: Jed Cunningham
Sent: Friday, July 21, 2023 7:45:02 AM
To: dev@airflow.apache.org
Subject: RE: [EXTERNAL][DISCUS
-1 (binding)
I think the eventual goal is all 3rd party executors (excluding Local,
Sequential, etc) are not pre-installed. I think it will take a while for us to
get there with Celery and K8s but it's the right thing to shoot for and we
should start with Dask.
I think in a perfect world we'd only have the completely vendor neutral
executors pre-installed (Local, Sequential, Debug) and anything else would need
to be specifically installed by admins/users. I think if we were starting from
scratch this would make the most sense, but clearly Kubernetes an
Congrats all! Very well deserved!
From: Wei Lee
Sent: Tuesday, June 27, 2023 11:29:10 PM
To: dev@airflow.apache.org
Subject: RE: [EXTERNAL][ANNOUNCE] New committers: Vincent Beck, Phani Kumar,
Maciej Obuchowski
CAUTION: This email originated from outside of the
+1 (binding)
From: Jarek Potiuk
Sent: Monday, June 19, 2023 7:38:08 AM
To: dev@airflow.apache.org
Subject: RE: [EXTERNAL][VOTE] AIP-56 Extensible user management
CAUTION: This email originated from outside of the organization. Do not click
links or open attachme
+1 (non-binding)
checked files, licenses, signatures, checksums, installation, and a few example
dags.
Cheers,
Niko
From: Beck, Vincent
Sent: Tuesday, June 13, 2023 12:32:39 PM
To: dev@airflow.apache.org
Subject: RE: [EXTERNAL][VOTE] Release Airflow 2.6.2 from
Woo! Congrats Prankaj!
From: Ankit Chaurasia
Sent: Monday, June 12, 2023 3:12:42 PM
To: dev@airflow.apache.org
Subject: RE: [EXTERNAL][ANNOUNCE] New committer: Pankaj Singh
CAUTION: This email originated from outside of the organization. Do not click
links or op
Congrats Hussein!
From: Sung Yun
Sent: Tuesday, April 11, 2023 4:41:15 PM
To: dev@airflow.apache.org
Subject: RE: [EXTERNAL][ANNOUNCE] New committer Hussein Awala
CAUTION: This email originated from outside of the organization. Do not click
links or open attachm
Chiming in on a few of the topics discussed so far:
- Context managers:
I found most of the context manager syntax proposals a little hard to
understand, but some better than others. Ultimately if I put my DAG author hat
on, I find this declaration the most straightforward, clear and it's easy t
I love this idea, it's definitely helpful!
I think an interesting topic to discuss for this project would be some kind of
UI based date/calendar picker to help users construct these logical
compositions. Something like `days("D1", "D2", "THU-SAT", "4>", "L1")` is quite
inscrutable.
A UI compone
I'd like to join as well! (oliveira...@gmail.com)
From: Igor Kholopov
Sent: Wednesday, March 22, 2023 4:01:40 PM
To: dev@airflow.apache.org
Subject: RE: [EXTERNAL]Request for feedback on proposal for new OpenLineage
provider in Airflow
CAUTION: This email origin
Congrats Brent!!
From: Jorrick Sleijster
Sent: Wednesday, March 15, 2023 9:09:07 AM
To: dev@airflow.apache.org
Subject: RE: [EXTERNAL][ANNOUNCE] New PMC member: Brent Bovenzi
CAUTION: This email originated from outside of the organization. Do not click
links or
Congrats Pierre, well deserved!
From: Kaxil Naik
Sent: Wednesday, March 15, 2023 2:47:31 AM
To: dev@airflow.apache.org
Subject: RE: [EXTERNAL][ANNOUNCE] New PMC member: Pierre Jeambrun
CAUTION: This email originated from outside of the organization. Do not click
+1 (non-binding). Checked files, install (using the newly updated pmc
Dockerfile :D), license and checksum.
From: Jarek Potiuk
Sent: Tuesday, March 7, 2023 1:53:26 PM
To: dev@airflow.apache.org
Subject: RE: [EXTERNAL][VOTE] Airflow Providers prepared on March 07,
I agree this is completely untenable, at least for Airflow. I commented on the
Jira ticket as well with more thoughts.
Cheers,
Niko
From: Jarek Potiuk
Sent: Monday, February 13, 2023 4:08:23 PM
To: dev@airflow.apache.org
Subject: RE: [EXTERNAL][NOTICE] Upcoming
+1 (binding)
Overall I think this will make future development and growth for OL in Airflow
much easier which will hopefully lead to more adoption!
From: Vikram Koka
Sent: Monday, February 13, 2023 8:20:23 AM
To: dev@airflow.apache.org
Subject: RE: [EXTERNAL][VOT
+1 (non-binding).
Installed the amazon provider rc and tested my tagged PR (and another while I
was at it).
Also checked svn file counts, installation, checksums and licenses
From: Jarek Potiuk
Sent: Thursday, February 9, 2023 12:31:20 PM
To: dev@airflow.apache.o
I would love to see this. I think it would legitimize the interface a bit more
and also help to encourage folks to not abuse/leak it in the future.
AIP-51 is close to completion, I'd say 80%. We've boiled off most of the easier
items and what's left is a few tricky decouplings (I have a PR for o
res, checksums, licences. all looks good.
On Mon, Jan 16, 2023 at 7:42 PM Oliveira, Niko
wrote:
+1 binding
Our system tests show the AWS provider package as stable, a couple known flakey
tests but we have regular passes with green across the board (public dashboard
coming very s
+1 binding
Our system tests show the AWS provider package as stable, a couple known flakey
tests but we have regular passes with green across the board (public dashboard
coming very soon!)
From: Pankaj Singh
Sent: Monday, January 16, 2023 10:20:00 AM
To: dev@ai
+1 (binding)
Cheers,
Niko
From: Kevin Yang
Sent: Monday, January 9, 2023 1:46:00 PM
To: dev@airflow.apache.org
Subject: RE: [EXTERNAL][VOTE] AIP-52 Automatic setup and teardown tasks
CAUTION: This email originated from outside of the organization. Do not click
+1 binding
I really like this one, happy to see it coming along nicely!
Cheers,
Niko
From: Tomasz Urbaszek
Sent: Friday, December 30, 2022 4:20 AM
To: dev@airflow.apache.org
Subject: RE: [EXTERNAL][VOTE] AIP-50 Trigger DAG UI Extension with Flexible
User Form
This has yet to be published by Google and Amazon - I know they are progressing
a lot on making the automation and publishing regular result of the System
tests from main in the way that we can verify that all tests pass - all that is
done outside of the community resources and maintenance (i.e.
Awesome to hear this!
I was really battling this issue last week, very excited for these
improvements, let me know if I can help.
Cheers,
Niko
From: Jarek Potiuk
Sent: Tuesday, December 6, 2022 5:54:07 AM
To: dev@airflow.apache.org
Subject: [EXTERNAL] [PROPOSAL
.com>> wrote:
Cool!
On Mon, Dec 5, 2022 at 9:16 PM Oliveira, Niko
wrote:
Hey folks!
As a follow-up, if you're interested in following along with this project or
even taking some tasks, I've created a dashboard using Github's new Projects
tool. You can see the backlog of t
e a live board, new tasks will be added as they come up, but the
general skeleton is there.
Cheers,
Niko
____
From: Oliveira, Niko
Sent: Monday, November 7, 2022 4:41:44 PM
To: dev@airflow.apache.org
Subject: RE: [EXTERNAL]Proposal to Remove Executor Coupling in Cor
1) users "peace of mind" as top priority: clarity of what they can
expect from Airflow, and avoiding surprises when upgrading
2) targeting minimal disruption to user's workflows (though we might
never reach absolute 100%)
3) making it easy for contributors and maintainers to decide on
breaking/non-
Congrats Andrey!
From: Jarek Potiuk
Sent: Thursday, December 1, 2022 11:29:14 PM
To: dev@airflow.apache.org
Subject: [EXTERNAL] [ANNOUNCE] New committer Andrey Anshin (Taragolis)
CAUTION: This email originated from outside of the organization. Do not click
links
Thanks for starting this discussion Jarek!
I think it's very important for us to get on the same page as a community about
this.
I'd love to go with a more flexible/common sense approach for considering
breaking changes, and in a perfect world I think this would be best. However, I
also think
Hey folks!
The voting for AIP-51 Removing Executor Coupling from Core Airlfow
(https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-51+Removing+Executor+Coupling+from+Core+Airlfow)
was completed on November 21, 2022, and I am happy announce the following
voting result:
*Binding (+6) Votes*
Hey folks!
I would like to start a vote for "AIP-51 - Removing Executor Coupling from Core
Airlfow".
You can find the AIP here:
https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-51+Removing+Executor+Coupling+from+Core+Airlfow
Discussion threads:
https://lists.apache.org/thread/yd4tcgyqft6
ility for users who implemented their own executors (not a
very popular one also because of those problems this AIP is aiming to
solve, but still we have to account for that).
I personally think if there are no objections, this one is ready to
start voting on.
J.
On Tue, Nov 8, 2022 at 1:42 AM Ol
!
From: Oliveira, Niko
Sent: Monday, October 24, 2022 2:28 PM
To: dev@airflow.apache.org
Subject: [EXTERNAL] Proposal to Remove Executor Coupling in Core Airlfow Code
Base
Hey all!
Recently I have spent some time investigating the occurrences of hardcoded
Executor logic within core
in the previous description we jumped straight to "labels" but
I believe (and that might be a good point to discuss with the current
triagers and committers) that labeling of priorities/etc. should be
somewhat "last" point of the triaging. We rarely (if at all) look at
those labels and IMHO there a
Thanks Jarek for the extra context and additions to the Traiging rst!
An update from my end as a new Triage member:
For the past few weeks I have looked at every single notification from Airflow
Github and it has been a very informative learning experience.
1. Beyond tagging and updating Is
Hey all!
Recently I have spent some time investigating the occurrences of hardcoded
Executor logic within core Airflow code and put together a mini-AIP of sorts on
Github Discussions (it was nice to use GH markdown and automatic code snippets).
I'm particularly interested to hear if folks think
e creator hasn't replied
Regards,
Kaxil
On Wed, 5 Oct 2022 at 17:32, Oliveira, Niko wrote:
Hey Elad!
Yupp, I read through that rst and I'm going to help triage incoming issues more
frequently. Though I do think reviewing the backlog of issues every quarter or
so can be a useful e
ges I encourage everyone to assist us by
simply commenting in issues. The act of close/set labels is not time consuming,
the real problem is actually handling the issues.
On Wed, Oct 5, 2022 at 6:15 PM Oliveira, Niko
wrote:
Hello folks,
Yesterday I attended a session at ApacheCon about bes
Hello folks,
Yesterday I attended a session at ApacheCon about best practices for managing
bug/issue backlogs for a project and it got me reflecting on the Airflow issue
backlog. I'd like to get more involved in initial (and continuous) triage of
Airflow issues on Github.
I chatted with Jarek
il.com>> wrote:
I don't think we have to limit ourselves that only the commiters have access to
the Amazon account managed by Airflow community. In the past, commiters was
supported by other people whom they trust e.g. commiter asked for help from
another co-worker from her company whe
Hey folks,
Those of us on the AWS Airflow team (myself, Dennis F, Vincent B, Seyed H) have
been working on a few projects over the past few months:
1. Writing example dags/docs for all existing Operators in the AWS Airflow
provider package (done)
2. Writing AWS specific logic in Airflow code
+1 I agree this is a logical next step towards possibly separating provider
code from the Airflow code base (and it's useful even if we never do that).
Cheers,
Niko
From: Kamil Breguła
Sent: Monday, June 20, 2022 1:30 PM
To: dev@airflow.apache.org
Subject: RE: [
> I hope we can - as part of system tests improvements - add it for other
> providers too :)
I plan to add the tests for AWS soon :)
From: Jarek Potiuk
Sent: Sunday, May 8, 2022 12:34 PM
To: dev@airflow.apache.org
Subject: RE: [EXTERNAL]Testing structure of you
> BTW. Seems that there is a problem that you STILL need write access to be
> CODEOWNER (despite the updated documentation :) )
Sad, I was also very excited about this. It would make the workflow of keeping
an eye on changes to code we "own" much easier. Fingers crossed it's a feature
coming so
Congrats Malthe, well deserved!
From: Vikram Koka
Sent: Monday, February 21, 2022 2:08 PM
To: dev@airflow.apache.org
Subject: RE: [EXTERNAL] New Commiter: Malthe Borch
CAUTION: This email originated from outside of the organization. Do not click
links or open a
Congrats Josh, well deserved!
From: Vikram Koka
Sent: Monday, February 21, 2022 2:07 PM
To: dev@airflow.apache.org
Subject: RE: [EXTERNAL] New committer: Josh Fell
CAUTION: This email originated from outside of the organization. Do not click
links or open attac
Hey folks,
I think both these sticking points are really a trade-off of simplicity vs
consistency/reliability. And to be clear I'm not arguing for things to be more
complex just for the heck of it, I agree that simplicity is great! But just
that there needs to be a balance and we can't get cau
Hey folks,
Very excited about this AIP!
I work on the AWS OSS Airflow team. Getting the AWS system tests running has
been a pet-project of mine for the past little while. I come from a test
automation background, so this is dear to my heart :)
Currently I have a branch that contains the impl
1 - 100 of 102 matches
Mail list logo