+1 (non-binding)

Really nice feature!

Best,
Aaron

On Sat, May 16, 2026 at 6:38 PM Shivam Rastogi <[email protected]>
wrote:

> +1 (non-binding)
>
> I successfully tested the coordinator with my TypeScript SDK. I also ran a
> DAG that mixed Java, TypeScript, and Python tasks in a single pipeline,
> exchanging data via XCom across all three runtimes. Every task ran
> successfully end-to-end.
>
> @TP and @Jason Do you think we can include the typescript sdk as part of
> this AIP or will it require a separate AIP? In my opinion, it
> doesn't require a new AIP as it will be an extension of the coordinator.
>
> Regards,
> Shivam Rastogi
>
> On Sat, 16 May 2026 at 11:36, Stefan Wang <[email protected]> wrote:
>
> > +1 (non-binding).
> >
> > Thanks TP and Jason
> >
> > — really appreciate the way the discussion feedback got worked into the
> > design, and the coordinator-interface shape that came out the other side.
> >
> > Excited to see this land as the foundation for native multi-language task
> > support in Airflow.
> >
> > Best,
> > Stefan
> >
> >
> > > On May 16, 2026, at 3:30 AM, Zhe-You(Jason) Liu <[email protected]>
> > wrote:
> > >
> > > Hi TP, Jens, Jarek, and all,
> > >
> > > +1 (binding) from me as well.
> > >
> > > I really appreciate all the thoughtful feedback and comments from
> > everyone
> > > that helped make AIP-108 and the coordinator interface more concrete. I
> > > look forward to the coordinator interface becoming a strong foundation
> > for
> > > native multi-language task support in Airflow and for future language
> > > integrations as well.
> > >
> > > Thanks everyone!
> > >
> > > Best,
> > > Jason
> > >
> > > On Sat, May 16, 2026 at 6:27 PM Phani Kumar via dev <
> > [email protected]>
> > > wrote:
> > >
> > >> +1 (binding). Thanks TP, Jarek, Jens and Jason for the discussion and
> > >> alignment.
> > >>
> > >> On Sat, May 16, 2026 at 3:26 PM Jarek Potiuk <[email protected]>
> wrote:
> > >>
> > >>> +1 (binding) -> Thanks for being receptive to all comments TP /
> Jason.
> > >>>
> > >>> And regarding Jens' point: yes, "naming is difficult". However, at
> this
> > >>> stage, this name is just a "codename" because it's "Java only,"
> > >>> "experimental," mostly used internally (except for the package name
> in
> > >>> configuration), and lacks a separate installable distribution (it's
> > just
> > >> a
> > >>> Python package name). When/If we turn it (hopefully soon) into
> > >> full-fledged
> > >>> coordinators - with common APIs and a compatibility strategy—it
> > **might**
> > >>> get real "coordinator" features; this might get handy. It might also
> be
> > >>> easier to "promote it" without migrations, which TP was rightfully
> > >>> concerned about.
> > >>>
> > >>> So, I actually like that it's named "coordinators" now in the Python
> > >>> package name because it allows for easy future evolution without
> > >>> unnecessary migration issues. I was far more sceptical about
> > implementing
> > >>> the new distribution naming schema at this point - because that would
> > >>> "anchor" us much more. I think our discussion resulted in a good
> middle
> > >>> ground: we avoid overcomplicating things (especially the development
> > >>> process, operational complexity, and intra-compatibility issues),
> > >> allowing
> > >>> us to get something "working" quickly, while ensuring we aren't
> blocked
> > >> and
> > >>> have a smooth path to implement the longer-term vision later.
> > >>>
> > >>> I think that was a very good discussion and outcome. Thanks again,
> TP.
> > >>> Also, thanks to (a bit more silent in this discussion) Jason for
> being
> > so
> > >>> flexible. I really appreciate it. I know firsthand how difficult it
> is
> > >> when
> > >>> a bigger vision you have is kind of trimmed-down, and when you see
> > where
> > >>> you want to go and others seem to "not see it". It forces you to
> twist
> > >> and
> > >>> turn things to not lose the track of the bigger vision, while taking
> > the
> > >>> first baby step toward it. But my experience is that the end result
> > might
> > >>> eventually benefit from learnings along the way, so trimming the
> first
> > >>> steps is a good thing (even if it's very difficult mentally). I've
> been
> > >>> doing it for years in our dev environment. While it generally follows
> > my
> > >>> initial vision, it's very different now due to incremental steps and
> > >>> tooling improvements along the way.
> > >>>
> > >>> J.
> > >>>
> > >>>
> > >>> On Sat, May 16, 2026 at 10:52 AM Shahar Epstein <[email protected]>
> > >> wrote:
> > >>>
> > >>>> +1 (binding), well done TP and Jason.
> > >>>>
> > >>>>
> > >>>> Shahar
> > >>>>
> > >>>> On Sat, May 16, 2026 at 10:02 AM Tzu-ping Chung via dev <
> > >>>> [email protected]> wrote:
> > >>>>
> > >>>>> Hi all,
> > >>>>>
> > >>>>> I’m calling vote on AIP-108: Java Task SDK and the Language
> > >> Coordinator
> > >>>>> Layer
> > >>>>> AIP-108 Java Task SDK and the Language Coordinator Layer - Airflow
> -
> > >>>>> Apache Software Foundation <
> > >>> https://cwiki.apache.org/confluence/x/pY4mGQ>
> > >>>>> cwiki.apache.org <https://cwiki.apache.org/confluence/x/pY4mGQ>
> > >>>>> [image: favicon.ico] <https://cwiki.apache.org/confluence/x/pY4mGQ
> >
> > >>>>> <https://cwiki.apache.org/confluence/x/pY4mGQ>
> > >>>>>
> > >>>>> Discussion thread:
> > >>>>> lists.apache.org
> > >>>>> <https://lists.apache.org/thread/gjot4bxj9kygj2fk76kx6tyg8s4hr057>
> > >>>>> [image: favicon.ico]
> > >>>>> <https://lists.apache.org/thread/gjot4bxj9kygj2fk76kx6tyg8s4hr057>
> > >>>>> <https://lists.apache.org/thread/gjot4bxj9kygj2fk76kx6tyg8s4hr057>
> > >>>>>
> > >>>>>
> > >>>>> The vote will run for 5 days until Thursday, 21st May 2026, 07:00
> > UTC.
> > >>>>>
> > >>>>> Everyone is encouraged to vote, but only PMC members and
> Committers'
> > >>>>> votes are considered binding.
> > >>>>>
> > >>>>> Please vote accordingly
> > >>>>>
> > >>>>> [ ] +1 Approve
> > >>>>> [ ] +0 no opinion
> > >>>>> [ ] -1 disapprove with the reason
> > >>>>>
> > >>>>> Consider this my +1 vote (binding)
> > >>>>>
> > >>>>> TP
> > >>>>>
> > >>>>
> > >>>
> > >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [email protected]
> > For additional commands, e-mail: [email protected]
> >
> >
>

Reply via email to