Kyungjun:
> dataflow graphs, event-driven DAGs, or asset-based workflows
I think you would have to clarify what you are asking for. I believe
(depending on the definition of all three), Airflow already supports all
three things you mentioned. Many of the things we implemented in Airflow 3
went way
> First we must arrive at something approaching consensus, which it seems
we have not ;)
Yeah. We can always eventually vote on it if we won't be able to convince
everyone :). But let me try again.
> sort of don't really understand why we would write Dag. It seems
kindof the worst of both worlds
First we must arrive at something approaching consensus, which it seems we
have not ;)
On Wed, Sep 3, 2025 at 4:14 PM Ferruzzi, Dennis
wrote:
> > I believe we should better document the decision this time.
>
> Hate to be That Guy, but what about (yet another) prek rule to enforce it?
>
>
> - fe
Hello,
This is a mailing list for the development of Airflow open source.
For commercial offerings you can contact the companies who offer Airflow as
a service. The list is available on
https://airflow.apache.org/ecosystem/#airflow-as-a-service
On Wed, Sep 3, 2025 at 4:31 PM Javier Alcaraz <
javi
Dear Airflow Team,
I hope this message finds you well.
I’m reaching out to request information regarding the pricing and features
included in your enterprise plan. We’re currently evaluating solutions for our
data transformation workflows and would appreciate details on what the
enterprise offer
Hello,
A while back I started a discussion on the mailing list regarding making
some changes to the task selection query in order to improve the
scheduler's throughput.
https://github.com/apache/airflow/pull/54103
Another topic came up during that discussion related to task starvation due
to the
I understand your point Elad, but introducing translation is a good way to get
new contributors involved in the project, so maybe we could find a way to
include the translation, and then if they don’t keep it up we remove the
translation at the next touch-point — so in this case introduce for 3.
100% agree with Daniel. "Dag" seems to be the worst choice out of all
options.
On Mon, Sep 1, 2025 at 10:54 PM Daniel Standish
wrote:
> I sort of don't really understand why we would write Dag. It seems
> kindof the worst of both worlds. That's not what the class is. And it
> doesn't really
Hi all,
I’m not sure if the Astronomer team has already started work on
implementing *AIP-76*, but I’ve prepared a proposal for how we could
approach the implementation.
The proposal covers:
-
Extending the asset/event model to support partitions
-
A normalized schema for asset eve
Lazy consensus passed. Conveniently, we just solved the last teething issue
with ARM Python 3.11 :)
On Fri, Aug 29, 2025 at 5:16 PM Jarek Potiuk wrote:
> Following discussion
> https://lists.apache.org/thread/z0yh528lkc1pfpjwlb3b3qbylg5do2jr -
> together with Aritra, we want to ask for a lazy co
Good job folks!
I would've loved to follow it more closely than I did!
Thanks & Regards,
Amogh Desai
On Sat, Aug 30, 2025 at 8:59 PM Jarek Potiuk wrote:
> Thanks to Aritra for leading it !!!
>
> On Sat, Aug 30, 2025 at 5:27 PM Aritra Basu
> wrote:
>
> > Woohoo! 🎉
> > --
> > Regards,
> > Arit
I sort of don't really understand why we would write Dag. It seems
kindof the worst of both worlds. That's not what the class is. And it
doesn't really make sense as a proper noun.
I would just use dag most of the time and DAG when you need to refer
unambiguously to the actual class.
On Sun,
This may be a slightly different topic from the current discussion, but I
hope it’s okay to ask here. Are there any ongoing or planned discussions
within the community about extending the concept of DAGs beyond the
traditional “task dependency graph” definition — for example, toward
dataflow graphs
13 matches
Mail list logo
