Yep. That's fine - I hope those who chimed-in before can confirm if their comments were addressed - Kaxil, Tattiana, Jason.
I am good with my comments :) On Wed, Jul 29, 2026 at 11:22 AM Dilnaz Amanzholova via dev < [email protected]> wrote: > Hi Jarek and Elad, > > I missed your comments before starting the re-vote thread yesterday, so > please accept my apologies. Do you know if there is a way to delete that > thread? > > Regarding the next steps, would it make sense to simply chime in on the > previous discussion thread? I would prefer to avoid starting yet another > new thread for this discussion. > > Link to initial discussion thread: > https://lists.apache.org/thread/wtfog0qjrf3oh7355db0x6mqk3o7l2dt > > Kind regards, > Dilnaz Amanzholova > > > On Mon, Jul 27, 2026 at 4:58 PM Jarek Potiuk <[email protected]> wrote: > > > Though - there were quite a lot of comments from Kaxil, Tatiana, Jason, > and > > myself, I think there was a convergence and I do not think any major > issues > > remain. > > > > Maybe Kaxil and Tatiana can chime in here. Perhaps starting a DISCUSS > > thread and explicitly calling for the people who chimed-in before to > > confirm the convergence + anyone else who might want to contribute, would > > be a good idea. > > > > And yes the VOTE thread here should be cancelled to avoid confusion. > > > > J. > > > > > > On Mon, Jul 27, 2026 at 1:42 PM Elad Kalif <[email protected]> wrote: > > > > > This thread doesn't show confidence there will be enough +1 votes and > to > > my > > > understanding there was supposed to be also a chat in dev call around > > this > > > AIP which didn't happen eventually. > > > The fact that people didn't comment back after raising some > > > initial question does not mean they will give +1. > > > Dilnaz this is your call how you want to move forward. I recommend > > revoking > > > this vote thread and starting a discussion thread. > > > Voting thread is **not** a call for opinions and thoughts. I only > joined > > > this thread because I was curious to see why it was not concluded. Some > > > other members of the community might not be aware that the discussion > is > > > still in fact open. Raising a discussion thread is how we call for the > > > community to be engaged. a voting thread does not serve that purpose. > > > again, you call. > > > > > > > > > > > > On Mon, Jul 27, 2026 at 1:52 PM Dilnaz Amanzholova via dev < > > > [email protected]> wrote: > > > > > > > Hi Jarek, > > > > > > > > Thanks for the feedback. With your comments addressed and if there > are > > no > > > > further objections, I will move AIP-85 to the voting phase tomorrow. > > > > > > > > Kind regards, > > > > Dilnaz Amanzholova > > > > > > > > > > > > On Sun, Jul 26, 2026 at 8:32 PM Jarek Potiuk <[email protected]> > wrote: > > > > > > > > > From my point of view - i think all my comments are really > addressed > > - > > > > > there is an impact to security model, but this is something that > can > > be > > > > > addressed as part of implementation, so from my point of view > > starting > > > a > > > > > vote in new thread seems like a good idea. > > > > > > > > > > On Thu, Jul 23, 2026 at 1:24 PM Dilnaz Amanzholova via dev < > > > > > [email protected]> wrote: > > > > > > > > > >> Hi Elad, > > > > >> > > > > >> Thank you for the suggestion. I will mark this thread as an > > additional > > > > >> discussion thread on the Confluence page. Once we address the > final > > > > points > > > > >> and are ready, I will open a new, separate thread to restart the > > > > official > > > > >> vote. > > > > >> > > > > >> Given that most of the major comments have already been > addressed, I > > > > hope > > > > >> we are close to the finish line and can restart the vote soon. > > > > >> > > > > >> Best regards, > > > > >> Dilnaz Amanzholova > > > > >> > > > > >> > > > > >> On Fri, Jul 17, 2026 at 9:20 PM Elad Kalif <[email protected]> > > > wrote: > > > > >> > > > > >> > I'd like to suggest revoking this vote thread and start a new > > > > discussion > > > > >> > thread to open up the discussion around the AIP. > > > > >> > > > > > >> > On Fri, Jul 17, 2026 at 2:35 AM Zhe-You(Jason) Liu < > > > > [email protected] > > > > >> > > > > > >> > wrote: > > > > >> > > > > > >> > > Hi Dilnaz, > > > > >> > > > > > > >> > > Thanks for your continued work refining the proposal. I'm > > looking > > > > >> forward > > > > >> > > to the DagImporter serving as the interface for processing > > native > > > > DAG > > > > >> > > definitions for Lang-SDK (Java, Go, and the upcoming > > TypeScript). > > > > >> > > > > > > >> > > I have one final question about the DagImporter interface. I > > left > > > a > > > > >> > comment > > > > >> > > on the Confluence doc yesterday, but I'm raising it here as > well > > > for > > > > >> > > visibility. > > > > >> > > > > > > >> > > Would it make sense to collapse supported_extensions() and > > > > >> can_handle() > > > > >> > > into list_dag_files()? > > > > >> > > > > > > >> > > Extension matching alone seems insufficient: for normal Python > > > DAGs, > > > > >> not > > > > >> > > all Python files are DAG files, and it's similar for the > > Java-SDK > > > -- > > > > >> not > > > > >> > > all JARs are valid Java-SDK entrypoint files. > > > > >> > > IIUC, list_dag_files() should be the single entrypoint that > > yields > > > > the > > > > >> > > valid DAG files for further processing. Since the files it > > yields > > > > >> should > > > > >> > be > > > > >> > > valid anyway, I don't think we'd need can_handle() as a > separate > > > > >> public > > > > >> > > interface. > > > > >> > > > > > > >> > > Happy to hear your thoughts on whether this makes sense, or if > > > > >> there's a > > > > >> > > reason to keep them separate that I'm missing. > > > > >> > > Thanks! > > > > >> > > > > > > >> > > Best regards, > > > > >> > > Jason > > > > >> > > > > > > >> > > On Mon, Jul 13, 2026 at 11:31 PM Dilnaz Amanzholova via dev < > > > > >> > > [email protected]> wrote: > > > > >> > > > > > > >> > > > Hi @Jarek Potiuk <[email protected]> and > > > > >> > > > < > > > > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > > > > > > > https://lists.apache.org/thread/df3f0z7l29nr9t5g2pvgxzpqvq74bv2w?content_ref=a+global+extension+importer+map+structurally+can+t+give+two+bundles+different+importers+for+the+same+extension+so+as+it+stands+the+foundation+can+t+support+the+resolution+model+the+aip+promises > > > > >> > > > >@Tatiana > > > > >> > > > Al-Chueyr <[email protected]> , > > > > >> > > > > > > > >> > > > Thank you so much for the detailed review and for supporting > > the > > > > >> > > > scoped-down direction. I completely agree with your > structural > > > > >> concerns > > > > >> > > > regarding the merged foundation in PR #60127. Reconciling > the > > > > >> intended > > > > >> > > > design in the AIP with what currently exists in main is > > > definitely > > > > >> the > > > > >> > > > right move before calling for a VOTE again. > > > > >> > > > > > > > >> > > > Here is how I am addressing your points, many of which align > > > with > > > > >> > recent > > > > >> > > > inline discussions on the AIP page: > > > > >> > > > > > > > >> > > > 1. Registry scope: You are right that a global extension -> > > > > importer > > > > >> > map > > > > >> > > > structurally cannot support the per-bundle resolution we > need. > > > > >> Tatiana > > > > >> > > also > > > > >> > > > brought this up in the inline comments. The intended > end-state > > > is > > > > >> > indeed > > > > >> > > > per-bundle instantiation with a strict bundle -> global -> > > > default > > > > >> > > > resolution > > > > >> > > > order. I will refactor the DagImporterRegistry out of the > > > > singleton > > > > >> > > pattern > > > > >> > > > to ensure the interface supports this scope. > > > > >> > > > > > > > >> > > > 2. *Archive* handling: I think we are aligned on using a > > > composite > > > > >> > > > ZipImporter. The AIP describes a generic archive importer > that > > > > >> > delegates > > > > >> > > to > > > > >> > > > internal-format importers, which provides the flexibility > > needed > > > > for > > > > >> > > > mixed-content archives (e.g., YAML and Python in the same > > zip). > > > I > > > > >> will > > > > >> > > > ensure the merged PythonDagImporter is updated to hand-over > > its > > > > >> > > > hard-ownership of .zip files. > > > > >> > > > > > > > >> > > > 3. Cross-file dependency tracking: Tatiana also raised the > > > > staleness > > > > >> > bug > > > > >> > > > issue for shared configurations like defaults.yaml. > > > > >> > > > < > > > > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > > > > > > > https://lists.apache.org/thread/df3f0z7l29nr9t5g2pvgxzpqvq74bv2w?content_ref=without+importer+declared+dependencies+a+change+to+a+shared+file+won+t+re+parse+its+dependents+a+staleness+bug > > > > >> > > > > > > > > >> > > > I > > > > >> > > > have updated the DagImportResult dataclass in the AIP to > > > include a > > > > >> > > > file_dependencies: > > > > >> > > > list[str] field. To clarify the interaction with the DAG > > > > Processor: > > > > >> the > > > > >> > > > custom importer will declare these dependencies, and the > core > > > DAG > > > > >> > > Processor > > > > >> > > > will cache them to monitor for modification time changes, > > > > >> triggering a > > > > >> > > > re-parse and a new DAG version when necessary (keeping the > > > > importers > > > > >> > > > stateless). > > > > >> > > > > > > > >> > > > 4. Security: This is a good point and something I hadn't > > > > explicitly > > > > >> > > defined > > > > >> > > > yet. Ensuring users don't treat YAML as a "review-free" data > > > > >> payload is > > > > >> > > > critical since resolving operators by classpath has the same > > > power > > > > >> as > > > > >> > > > arbitrary Python. > > > > >> > > > < > > > > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > > > > > > > https://lists.apache.org/thread/df3f0z7l29nr9t5g2pvgxzpqvq74bv2w?content_ref=explicitly+that+a+declarative+dag+file+is+fully+code+equivalent+trust+a+yaml+importer+resolving+operators+by+classpath+has+the+same+power+as+arbitrary+python > > > > >> > > > > > > > > >> > > > I > > > > >> > > > would love to take you up on your offer to help fill in > these > > > > >> security > > > > >> > > > blanks! I will add a dedicated "Security and Trust Model" > > > section > > > > to > > > > >> > the > > > > >> > > > AIP for the constraints you mentioned, feel free to modify > it. > > > > >> > Overall, I > > > > >> > > > would like to learn more about this if you don't mind, as > this > > > is > > > > my > > > > >> > > first > > > > >> > > > Airflow community contribution and it would be great to fill > > in > > > > the > > > > >> > > > knowledge blanks. > > > > >> > > > > > > > >> > > > 5. Safe mode: Yes, the "airflow + dag" string check is > > strictly > > > > >> > > > Python-specific and will fail for YAML. > > > > >> > > > < > > > > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > > > > > > > https://lists.apache.org/thread/df3f0z7l29nr9t5g2pvgxzpqvq74bv2w?content_ref=heuristic+file+contains+the+strings+airflow+dag+currently+lives+in+the+abstract+list_dag_files+but+it+s+python+specific+and+will+mis+handle+yaml+it+should+be+delegated+per+importer > > > > >> > > > >The > > > > >> > > > design on the AIP now clarifies that the safe_mode heuristic > > is > > > > >> > delegated > > > > >> > > > to individual importers by overriding the can_handle() > method, > > > > >> allowing > > > > >> > > > each format to define its own fast content-level checks. > > > > >> > > > > > > > >> > > > 6. Performance regression: I have added a section to the > AIP's > > > > >> > > > "Considerations" to include performance testing. This will > > > include > > > > >> > > > benchmarking basic, large-volume .py workloads to ensure the > > new > > > > >> > registry > > > > >> > > > indirection adds no measurable regression, > > > > >> > > > < > > > > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > > > > > > > https://lists.apache.org/thread/df3f0z7l29nr9t5g2pvgxzpqvq74bv2w?content_ref=it+d+be+good+to+confirm+the+registry+indirection+adds+no+measurable+regression+on+the+plain+py+path+some+performance+tests+with+basic+big+numbers+of+dags+scenarios+would+be+great+to+do+as+part+of+the+implementation > > > > >> > > > > > > > > >> > > > alongside > > > > >> > > > comparative benchmarks of native YAML vs. legacy generator > > > > patterns > > > > >> > > (e.g., > > > > >> > > > dag-factory). > > > > >> > > > > > > > >> > > > How should we proceed with the discussion logistics? I can > > > either > > > > >> copy > > > > >> > > the > > > > >> > > > relevant points from this thread over to the main [DISCUSS] > > > > thread, > > > > >> or > > > > >> > > > simply link this thread there as another reference. Once the > > > > >> feedback > > > > >> > is > > > > >> > > > incorporated and the AIP is ready to transition back to the > > > voting > > > > >> > > phase, I > > > > >> > > > can then open a new thread, perhaps titled [FINAL VOTE]. > > > > >> > > > > > > > >> > > > Let me know on your thoughts on this as I don't have strong > > > > >> preference. > > > > >> > > > > > > > >> > > > Kind regards, > > > > >> > > > Dilnaz Amanzholova > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > On Wed, Jul 8, 2026 at 3:42 PM Jarek Potiuk < > [email protected] > > > > > > > >> wrote: > > > > >> > > > > > > > >> > > > > 100% on what Tatiana wrote :D > > > > >> > > > > > > > > >> > > > > On Wed, Jul 8, 2026 at 3:06 PM Tatiana Al-Chueyr Martins < > > > > >> > > > > [email protected]> wrote: > > > > >> > > > > > > > > >> > > > >> Thanks a lot for being so responsive to the feedback on > the > > > AIP > > > > >> > > > Confluent > > > > >> > > > >> page, Dilnaz. Since yesterday, you've added > > file_dependencies > > > > to > > > > >> > > > >> DagImportResult, introduced a DagSource class that > carries > > > the > > > > >> > source > > > > >> > > > >> language for the Code tab, and made the importer > precedence > > > > order > > > > >> > > > explicit > > > > >> > > > >> (bundle explicit mapping > global config > defaults) - > all > > > > great > > > > >> > > > >> improvements. > > > > >> > > > >> > > > > >> > > > >> I agree with Jarek on reconciling the merged foundation > > with > > > > the > > > > >> AIP > > > > >> > > > >> (particularly the per-bundle registry) before re-running > > the > > > > >> vote. > > > > >> > And > > > > >> > > > >> yeah, explicitly stating that a declarative DAG file > > carries > > > > the > > > > >> > same > > > > >> > > > >> trust > > > > >> > > > >> level as the Python code is important - in our > experience, > > > > users > > > > >> > often > > > > >> > > > >> think YAML is just data, so we should make this explicit. > > > > >> > > > >> > > > > >> > > > >> On the zip question, composite importers feel like the > > right > > > > path > > > > >> > > > forward. > > > > >> > > > >> Once we get non-Python formats treated as first-class > > > citizens, > > > > >> it > > > > >> > > feels > > > > >> > > > >> like the next natural step is mixed content. Delegating > to > > > > inner > > > > >> > > > importers > > > > >> > > > >> handles that cleanly, whereas I feel that extending > > > > >> > PythonDagImporter > > > > >> > > > >> wouldn't scale as well. > > > > >> > > > >> > > > > >> > > > >> It does feel we should wrap up the bigger questions in > > > > [DISCUSS] > > > > >> - > > > > >> > > this > > > > >> > > > >> will allow maintainers to VOTE on the proposed design > with > > > > >> > confidence, > > > > >> > > > and > > > > >> > > > >> the AIP will be stronger with it. With the pace I've > > observed > > > > >> since > > > > >> > > > >> yesterday, it doesn't feel like we're far off - looking > > > forward > > > > >> to > > > > >> > > > seeing > > > > >> > > > >> it back into VOTE. > > > > >> > > > >> > > > > >> > > > >> Kind regards, > > > > >> > > > >> > > > > >> > > > >> Tatiana > > > > >> > > > >> > > > > >> > > > >> On Wed, 8 Jul 2026 at 13:24, Jarek Potiuk < > > [email protected]> > > > > >> wrote: > > > > >> > > > >> > > > > >> > > > >> > Hi Dilnaz, and indeed - thanks for pushing this > forward. > > > > >> > > > >> > > > > > >> > > > >> > The scoped-down "DAG importer" framing is much clearer, > > and > > > > >> > > > >> > native non-Python DAGs are a genuinely good direction. > +1 > > > on > > > > >> the > > > > >> > > goal. > > > > >> > > > >> > > > > > >> > > > >> > I am happy to make comments and suggestions or even > > fill-in > > > > >> some > > > > >> > > > blanks > > > > >> > > > >> > (security especially) in the AIP proposal if you are > fine > > > > with > > > > >> me > > > > >> > > > doing > > > > >> > > > >> it > > > > >> > > > >> > - see > > > > >> > > > >> > some of the comments below. > > > > >> > > > >> > > > > > >> > > > >> > Before I can vote on the design, I'd like to raise one > > > > >> structural > > > > >> > > > >> concern > > > > >> > > > >> > plus a couple of smaller ones. My main point is that > the > > > > >> > foundation > > > > >> > > > >> already > > > > >> > > > >> > merged in https://github.com/apache/airflow/pull/60127 > > > > >> > > > >> > contradicts the design the AIP describes, and I think > we > > > > >> > > > >> > should reconcile the two before the vote closes rather > > than > > > > >> after. > > > > >> > > > >> > > > > > >> > > > >> > Some of these points are already explicitly stated, > > either > > > in > > > > >> the > > > > >> > > AIP > > > > >> > > > or > > > > >> > > > >> > opened > > > > >> > > > >> > questions raised by Tatiana - I just want to reiterate > > them > > > > >> here > > > > >> > and > > > > >> > > > >> see if > > > > >> > > > >> > we can > > > > >> > > > >> > reach consensus on the shape of those changes. > > > > >> > > > >> > > > > > >> > > > >> > Concretely, in > > > > >> airflow-core/src/airflow/dag_processing/importers/: > > > > >> > > > >> > > > > > >> > > > >> > 1. Registry scope — global singleton vs. per-bundle. > The > > > AIP > > > > >> > > describes > > > > >> > > > >> > per-bundle importer mapping with a bundle -> global -> > > > > default > > > > >> > > > >> resolution > > > > >> > > > >> > order (and Tatiana's Q4/Q7 ask for the same). But the > > > merged > > > > >> > > > >> > DagImporterRegistry is a process-wide singleton keyed > by > > > > >> > extension, > > > > >> > > > >> "last > > > > >> > > > >> > registered wins, one importer per extension." A global > > > > >> > > > >> extension->importer > > > > >> > > > >> > map structurally can't give two bundles different > > importers > > > > for > > > > >> > the > > > > >> > > > same > > > > >> > > > >> > extension, so as it stands the foundation can't support > > the > > > > >> > > resolution > > > > >> > > > >> > model the AIP promises. If per-bundle is the intended > end > > > > >> state, I > > > > >> > > > >> think we > > > > >> > > > >> > want that in the interface now, because swapping a > > > singleton > > > > >> out > > > > >> > > later > > > > >> > > > >> is > > > > >> > > > >> > expensive. > > > > >> > > > >> > > > > > >> > > > >> > 2. Zip handling. The AIP describes a generic > ZipImporter > > > that > > > > >> > > > delegates > > > > >> > > > >> to > > > > >> > > > >> > inner-format importers. The merged PythonDagImporter > > > instead > > > > >> > > hard-owns > > > > >> > > > >> both > > > > >> > > > >> > .py and .zip, with a docstring saying YAML-in-zip would > > > > require > > > > >> > > > >> extending > > > > >> > > > >> > it > > > > >> > > > >> > or writing a composite importer — the opposite of the > > > AIP. I > > > > >> > think > > > > >> > > we > > > > >> > > > >> > should > > > > >> > > > >> > decide on one or the other direction, I like the > > composite > > > > >> > importer > > > > >> > > > >> more - > > > > >> > > > >> > even > > > > >> > > > >> > if it is more complex, it allows for greater > flexibility > > if > > > > we > > > > >> > have > > > > >> > > > >> > composite > > > > >> > > > >> > importers. But I would love to hear what others think. > > > > >> > > > >> > > > > > >> > > > >> > 3. DagImportResult.file_dependencies is in the AIP > > > dataclass > > > > >> but > > > > >> > not > > > > >> > > > in > > > > >> > > > >> the > > > > >> > > > >> > merged one — and this is more than cosmetic. > Declarative > > > DAGs > > > > >> > > > routinely > > > > >> > > > >> > share a defaults.yaml; the DFP decides what to re-parse > > > from > > > > >> > > per-file > > > > >> > > > >> > mtime, > > > > >> > > > >> > so without importer-declared dependencies a change to a > > > > shared > > > > >> > file > > > > >> > > > >> won't > > > > >> > > > >> > re-parse its dependents (a staleness bug). This is > > > Tatiana's > > > > >> Q5, > > > > >> > and > > > > >> > > > I'd > > > > >> > > > >> > treat it as a correctness requirement, not a > > nice-to-have. > > > > >> Worth > > > > >> > > > >> spelling > > > > >> > > > >> > out how it interacts with AIP-66's git-sha bundle > > > versioning > > > > >> too. > > > > >> > > > >> > > > > > >> > > > >> > On security, I'd like the AIP to state explicitly that > a > > > > >> > declarative > > > > >> > > > DAG > > > > >> > > > >> > file is fully code-equivalent trust: a YAML importer > > > > resolving > > > > >> > > > >> operators by > > > > >> > > > >> > classpath has the same power as arbitrary Python. > People > > > tend > > > > >> to > > > > >> > > treat > > > > >> > > > >> YAML > > > > >> > > > >> > as "data" and .py as "code," and I want to make sure > > nobody > > > > >> > builds a > > > > >> > > > >> > "review-free YAML bundle" path on the back of this. I'd > > > also > > > > >> like > > > > >> > it > > > > >> > > > >> stated > > > > >> > > > >> > as a hard constraint that importers run only in the DAG > > > > >> processor, > > > > >> > > > >> > in-process, under the same parse timeout, and never > touch > > > the > > > > >> > > metadata > > > > >> > > > >> DB — > > > > >> > > > >> > consistent with the AIP-66/AIP-72 boundary. And a quick > > > > >> > confirmation > > > > >> > > > >> that > > > > >> > > > >> > the old "push DAGs over API / ingester" idea stays out > of > > > > >> scope, > > > > >> > > since > > > > >> > > > >> that > > > > >> > > > >> > one genuinely changes the threat model. > > > > >> > > > >> > > > > > >> > > > >> > Again, for security, if you are happy with it, I would > > love > > > > to > > > > >> be > > > > >> > > able > > > > >> > > > >> to > > > > >> > > > >> > fill > > > > >> > > > >> > all those security blanks - this can be described on > high > > > > >> level in > > > > >> > > the > > > > >> > > > >> AIP, > > > > >> > > > >> > and when implementation progresses, it would turn into > > > > security > > > > >> > > model > > > > >> > > > >> > updates (I'm also happy to help there). > > > > >> > > > >> > > > > > >> > > > >> > Two smaller things: > > > > >> > > > >> > > > > > >> > > > >> > - The safe_mode/might_contain_dag heuristic ("file > > contains > > > > the > > > > >> > > > strings > > > > >> > > > >> > airflow + dag") currently lives in the abstract > > > > list_dag_files, > > > > >> > but > > > > >> > > > it's > > > > >> > > > >> > Python-specific and will mis-handle YAML — it should be > > > > >> delegated > > > > >> > > > >> > per-importer (Tatiana's Q3). > > > > >> > > > >> > > > > > >> > > > >> > - It'd be good to confirm the registry indirection adds > > no > > > > >> > > measurable > > > > >> > > > >> > regression on the plain .py path - some performance > tests > > > > with > > > > >> > basic > > > > >> > > > >> > big-numbers-of-dags scenarios would be great to do as > > part > > > of > > > > >> the > > > > >> > > > >> > implementation. > > > > >> > > > >> > > > > > >> > > > >> > None of this is a blocker on the idea — I'm supportive. > > But > > > > >> given > > > > >> > > the > > > > >> > > > >> open > > > > >> > > > >> > design questions and that the vote has been quiet, It > > > > >> reaffirms we > > > > >> > > > treat > > > > >> > > > >> > this > > > > >> > > > >> > as still in [DISCUSS], reconcile the AIP with the > merged > > > > >> > foundation > > > > >> > > > >> > (especially point 1), and re-run the vote once the > > > interface > > > > >> > > reflects > > > > >> > > > >> the > > > > >> > > > >> > intended end state. > > > > >> > > > >> > > > > > >> > > > >> > Happy to help review the per-bundle registry shape. > > > > >> > > > >> > > > > > >> > > > >> > Best, > > > > >> > > > >> > Jarek > > > > >> > > > >> > > > > > >> > > > >> > On Tue, Jul 7, 2026 at 4:45 PM Tatiana Al-Chueyr > Martins > > < > > > > >> > > > >> > [email protected]> wrote: > > > > >> > > > >> > > > > > >> > > > >> > > Hi Dilnaz, > > > > >> > > > >> > > > > > > >> > > > >> > > Thanks a lot for pushing this forward, and for the > > > updates > > > > >> after > > > > >> > > the > > > > >> > > > >> > > earlier feedback - AIP 85 looks much clearer than > > before. > > > > >> > > > >> > > > > > > >> > > > >> > > I'm one of the maintainers of DAG Factory ( > > > > >> > > > >> > > https://github.com/astronomer/dag-factory), and I > like > > > the > > > > >> > > > direction > > > > >> > > > >> the > > > > >> > > > >> > > AIP is taking. I agree with the pain points Igor > raised > > > > >> earlier; > > > > >> > > it > > > > >> > > > >> would > > > > >> > > > >> > > be great to support non-Python DAGs natively in > > Airflow, > > > > >> rather > > > > >> > > than > > > > >> > > > >> > > converting them as we currently do in DAG Factory. > > > > >> > > > >> > > > > > > >> > > > >> > > I've reviewed the AIP page and left some inline > > comments > > > & > > > > >> > > > questions. > > > > >> > > > >> > Since > > > > >> > > > >> > > the authors are already responding on the AIP page, > > happy > > > > to > > > > >> > > > continue > > > > >> > > > >> the > > > > >> > > > >> > > detailed discussion there - sharing the summary here > > > mainly > > > > >> for > > > > >> > > > >> > visibility: > > > > >> > > > >> > > > > > > >> > > > >> > > 1. *Location of schemas and importers*: Where do we > see > > > the > > > > >> > > schemas > > > > >> > > > >> and > > > > >> > > > >> > > actual importers defined - and how do we plan to > govern > > > > them? > > > > >> > It > > > > >> > > > >> would > > > > >> > > > >> > be > > > > >> > > > >> > > important to align, for instance, on how > non-primitive > > > > >> operator > > > > >> > > > >> arguments > > > > >> > > > >> > > should be defined in YAML (e.g., Asset, V1Pod, > > arbitrary > > > > >> > classes) > > > > >> > > > and > > > > >> > > > >> on > > > > >> > > > >> > > the security aspects of loading arbitrary classes > from > > > > YAML. > > > > >> > > > >> > > > > > > >> > > > >> > > 2. *Validation contract*: If users define unknown or > > > > >> unsupported > > > > >> > > > keys > > > > >> > > > >> and > > > > >> > > > >> > > configurations, should we fail loudly with > > > DagImportErrors > > > > >> > > > referencing > > > > >> > > > >> > > files/lines like the Python DAG import errors? It > would > > > be > > > > >> great > > > > >> > > if > > > > >> > > > we > > > > >> > > > >> > > didn't just skip them. > > > > >> > > > >> > > > > > > >> > > > >> > > 3.* Decision on which files to parse: *As raised by > TP > > on > > > > >> > > > >> > > < > > > > >> > > > >> > > > > > > >> > > > >> > > > > > >> > > > >> > > > > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > > > > > > > https://docs.google.com/document/d/1K6-4cGoZItXGQHZjOydNbc7rGtOp_XKfFurMnFptKe0/edit?disco=AAAB8ofIMRo > > > > >> > > > >> > > > > > > > >> > > > >> > > the > > > > >> > > > >> > > Google > > > > >> > > > >> > > < > > > > >> > > > >> > > > > > > >> > > > >> > > > > > >> > > > >> > > > > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > > > > > > > https://docs.google.com/document/d/1K6-4cGoZItXGQHZjOydNbc7rGtOp_XKfFurMnFptKe0/edit?disco=AAAB8ofIMRo > > > > >> > > > >> > > > > > > > >> > > > >> > > Doc > > > > >> > > > >> > > < > > > > >> > > > >> > > > > > > >> > > > >> > > > > > >> > > > >> > > > > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > > > > > > > https://docs.google.com/document/d/1K6-4cGoZItXGQHZjOydNbc7rGtOp_XKfFurMnFptKe0/edit?disco=AAAB8ofIMRo > > > > >> > > > >> > > > > > > > >> > > > >> > > , I feel that we should have additional criteria to > > > decide > > > > >> which > > > > >> > > > >> files to > > > > >> > > > >> > > treat as a DAG - and not rely only on the file > > extension. > > > > As > > > > >> an > > > > >> > > > >> example, > > > > >> > > > >> > > bundles normally have non-DAG YAML - dbt_project.yml, > > CI > > > > >> > configs, > > > > >> > > > K8s > > > > >> > > > >> > > manifests. Would it make sense to have something > > similar > > > to > > > > >> the > > > > >> > > > Python > > > > >> > > > >> > > content-level heuristic ("airflow + dag" string > check)? > > > > >> > > > >> > > > > > > >> > > > >> > > 4. *Different importers for the same file extension*: > > > > >> Can/should > > > > >> > > we > > > > >> > > > >> > support > > > > >> > > > >> > > different importers for the same file extension? It > > would > > > > be > > > > >> > great > > > > >> > > > if > > > > >> > > > >> the > > > > >> > > > >> > > architecture could support overriding the importer > per > > > > file. > > > > >> > > > >> > > > > > > >> > > > >> > > 5.* Cross-file dependency tracking:* Declarative DAGs > > are > > > > >> rarely > > > > >> > > > >> > > single-file. They can share default definitions, for > > > > example: > > > > >> > > > >> > > > > > > >> > > > >> > > > > >> > > > > > > >> > > > https://astronomer.github.io/dag-factory/1.1.0/configuration/defaults/ > . > > > > >> > > > >> > > Could importers declare file dependencies in > > > > >> DagImportResult, so > > > > >> > > the > > > > >> > > > >> > > processor can use them? > > > > >> > > > >> > > > > > > >> > > > >> > > 6. *Code tab UI*: On get_source_code(), could we > have a > > > > >> > parameter > > > > >> > > > >> related > > > > >> > > > >> > > to the file language, which could be used by the Code > > tab > > > > >> (it is > > > > >> > > > >> > currently > > > > >> > > > >> > > hard-coded with Python)? How are we planning to > resolve > > > > >> > > ZipImporter > > > > >> > > > >> and > > > > >> > > > >> > > other transformed sources in the UI? > > > > >> > > > >> > > > > > > >> > > > >> > > 7. *Precedence*: What should be the precedence > > > (per-bundle > > > > vs > > > > >> > > global > > > > >> > > > >> vs > > > > >> > > > >> > > default importers)? > > > > >> > > > >> > > > > > > >> > > > >> > > For the performance questions raised earlier in the > > > thread, > > > > >> we > > > > >> > > could > > > > >> > > > >> use > > > > >> > > > >> > > DAG Factory workloads as a baseline, comparing the > > > > >> > > > >> non-built-in-Airflow > > > > >> > > > >> > > Python layer against a native YAML importer. > > > > >> > > > >> > > > > > > >> > > > >> > > Our team is very keen to contribute to the YAML > > contract > > > > >> > > definition. > > > > >> > > > >> > > > > > > >> > > > >> > > Kind regards, > > > > >> > > > >> > > > > > > >> > > > >> > > Tatiana > > > > >> > > > >> > > > > > > >> > > > >> > > > > > > >> > > > >> > > On Tue, 7 Jul 2026 at 13:48, Dilnaz Amanzholova via > > dev < > > > > >> > > > >> > > [email protected]> wrote: > > > > >> > > > >> > > > > > > >> > > > >> > > > Hi all, I am following up to request your feedback > on > > > > >> AIP-85: > > > > >> > > DAG > > > > >> > > > >> > > importer. > > > > >> > > > >> > > > I attempted to present this at the last Airflow dev > > > call, > > > > >> but > > > > >> > > the > > > > >> > > > >> > agenda > > > > >> > > > >> > > > was full, and today’s meeting was unfortunately > > > > cancelled. > > > > >> As > > > > >> > it > > > > >> > > > has > > > > >> > > > >> > been > > > > >> > > > >> > > > some time since this AIP was submitted for review, > I > > > > would > > > > >> > > greatly > > > > >> > > > >> > > > appreciate it if you could share your thoughts or > any > > > > >> > remaining > > > > >> > > > >> > concerns > > > > >> > > > >> > > > here. I understand there are many active > discussions, > > > but > > > > >> your > > > > >> > > > input > > > > >> > > > >> > > would > > > > >> > > > >> > > > be invaluable in helping move this proposal > forward. > > > > >> Thanks, > > > > >> > > > Dilnaz > > > > >> > > > >> > > > Amanzholova > > > > >> > > > >> > > > > > > > >> > > > >> > > > On Thu, Jun 18, 2026 at 2:08 PM Dilnaz Amanzholova > < > > > > >> > > > >> [email protected] > > > > >> > > > >> > > > > > > >> > > > >> > > > wrote: > > > > >> > > > >> > > > > > > > >> > > > >> > > > > Hey Kaxil, > > > > >> > > > >> > > > > > > > > >> > > > >> > > > > Thanks for the clarification. I have decided to > > > attend, > > > > >> as > > > > >> > the > > > > >> > > > >> next > > > > >> > > > >> > > > > meeting is not for another two weeks. I have > added > > > the > > > > >> AIP > > > > >> > to > > > > >> > > > the > > > > >> > > > >> > > agenda. > > > > >> > > > >> > > > > > > > > >> > > > >> > > > > Best regards, > > > > >> > > > >> > > > > Dilnaz Amanzholova > > > > >> > > > >> > > > > > > > > >> > > > >> > > > > > > > > >> > > > >> > > > > On Wed, Jun 17, 2026 at 6:37 PM Kaxil Naik < > > > > >> > > [email protected] > > > > >> > > > > > > > > >> > > > >> > > wrote: > > > > >> > > > >> > > > > > > > > >> > > > >> > > > >> Hey not required at all. > > > > >> > > > >> > > > >> > > > > >> > > > >> > > > >> This is just in case you wanted to solicit > > feedback > > > > >> live on > > > > >> > > the > > > > >> > > > >> call > > > > >> > > > >> > > > with > > > > >> > > > >> > > > >> other Airflow devs. Sometimes it is easier that > > way > > > -- > > > > >> but > > > > >> > > not > > > > >> > > > >> > > > mandatory. > > > > >> > > > >> > > > >> > > > > >> > > > >> > > > >> More details on the dev calls: > > > > >> > > > >> > > > >> > > > > >> > > > >> > > > > > >> > > > > > > https://cwiki.apache.org/confluence/display/AIRFLOW/Airflow+Dev+Call > > > > >> > > > >> > > if > > > > >> > > > >> > > > >> you decide about presenting it next time. > > > > >> > > > >> > > > >> > > > > >> > > > >> > > > >> Regards, > > > > >> > > > >> > > > >> Kaxil > > > > >> > > > >> > > > >> > > > > >> > > > >> > > > >> On Wed, 17 Jun 2026 at 17:32, Dilnaz > Amanzholova < > > > > >> > > > >> > [email protected]> > > > > >> > > > >> > > > >> wrote: > > > > >> > > > >> > > > >> > > > > >> > > > >> > > > >>> Hi Kaxil, > > > > >> > > > >> > > > >>> > > > > >> > > > >> > > > >>> I was not aware there was a regular call. Is it > > > > >> required > > > > >> > to > > > > >> > > > >> present > > > > >> > > > >> > > the > > > > >> > > > >> > > > >>> AIP before voting? > > > > >> > > > >> > > > >>> > > > > >> > > > >> > > > >>> Kind regards, > > > > >> > > > >> > > > >>> Dilnaz Amanzholova > > > > >> > > > >> > > > >>> > > > > >> > > > >> > > > >>> > > > > >> > > > >> > > > >>> On Wed, Jun 17, 2026 at 6:26 PM Kaxil Naik < > > > > >> > > > [email protected] > > > > >> > > > >> > > > > > >> > > > >> > > > wrote: > > > > >> > > > >> > > > >>> > > > > >> > > > >> > > > >>>> Hi @dilnaz -- Are you up for presenting it > > > tomorrow > > > > >> or on > > > > >> > > the > > > > >> > > > >> next > > > > >> > > > >> > > dev > > > > >> > > > >> > > > >>>> call? > > > > >> > > > >> > > > >>>> > > > > >> > > > >> > > > >>>> > > > > >> > > > >> > > > >>>> > > > > >> > > > >> > > > >>>> On Tue, 16 Jun 2026 at 15:15, Dilnaz > Amanzholova > > > via > > > > >> dev > > > > >> > < > > > > >> > > > >> > > > >>>> [email protected]> wrote: > > > > >> > > > >> > > > >>>> > > > > >> > > > >> > > > >>>>> Hi all, > > > > >> > > > >> > > > >>>>> > > > > >> > > > >> > > > >>>>> I am following up on AIP-85: DAG importer. > All > > > > >> previous > > > > >> > > > >> concerns > > > > >> > > > >> > > have > > > > >> > > > >> > > > >>>>> been > > > > >> > > > >> > > > >>>>> addressed, and the content has been updated > on > > > the > > > > >> AIP > > > > >> > > > >> Confluence > > > > >> > > > >> > > > page. > > > > >> > > > >> > > > >>>>> > > > > >> > > > >> > > > >>>>> Please review the latest updates at your > > earliest > > > > >> > > > >> convenience. I > > > > >> > > > >> > > > would > > > > >> > > > >> > > > >>>>> appreciate your feedback and am available to > > > answer > > > > >> any > > > > >> > > > >> further > > > > >> > > > >> > > > >>>>> questions > > > > >> > > > >> > > > >>>>> you may have. > > > > >> > > > >> > > > >>>>> > > > > >> > > > >> > > > >>>>> Best regards, > > > > >> > > > >> > > > >>>>> Dilnaz Amanzholova > > > > >> > > > >> > > > >>>>> > > > > >> > > > >> > > > >>>>> > > > > >> > > > >> > > > >>>>> On Fri, Jun 5, 2026 at 1:23 PM Dilnaz > > > Amanzholova < > > > > >> > > > >> > > > [email protected]> > > > > >> > > > >> > > > >>>>> wrote: > > > > >> > > > >> > > > >>>>> > > > > >> > > > >> > > > >>>>> > Hi all, > > > > >> > > > >> > > > >>>>> > > > > > >> > > > >> > > > >>>>> > I’m calling vote on AIP-85: DAG importer > > > > >> > > > >> > > > >>>>> > > https://cwiki.apache.org/confluence/x/_Q7OEg > > > > >> > > > >> > > > >>>>> > > > > > >> > > > >> > > > >>>>> > You can also review the design document > here > > > > >> > > > >> > > > >>>>> > < > > > > >> > > > >> > > > >>>>> > > > > >> > > > >> > > > > > > > >> > > > >> > > > > > > >> > > > >> > > > > > >> > > > >> > > > > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > > > > > > > https://docs.google.com/document/d/1K6-4cGoZItXGQHZjOydNbc7rGtOp_XKfFurMnFptKe0/edit?tab=t.0 > > > > >> > > > >> > > > >>>>> > > > > > >> > > > >> > > > >>>>> > . > > > > >> > > > >> > > > >>>>> > > > > > >> > > > >> > > > >>>>> > Current discussion thread (after scoping > > down): > > > > >> > > > >> > > > >>>>> > > > > > >> > > > >> > > > > > >> https://lists.apache.org/thread/wtfog0qjrf3oh7355db0x6mqk3o7l2dt > > > > >> > > > >> > > > >>>>> > Original discussion thread (with wider > > > > "extendable > > > > >> DAG > > > > >> > > > >> parsing > > > > >> > > > >> > > > >>>>> controls" > > > > >> > > > >> > > > >>>>> > title): > > > > >> > > > >> > > > >>>>> > > > > >> > > > >> > > > > https://lists.apache.org/thread/bn0oo47j48xh8r335gd2jrrjz0o7vnjl > > > > >> > > > >> > > > >>>>> > > > > > >> > > > >> > > > >>>>> > The vote will run for 5 days, closing on > > > > Wednesday, > > > > >> > 10th > > > > >> > > > >> June > > > > >> > > > >> > > 2026, > > > > >> > > > >> > > > >>>>> at > > > > >> > > > >> > > > >>>>> > 10: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 > > > > >> > > > >> > > > >>>>> > > > > > >> > > > >> > > > >>>>> > Kind regards, > > > > >> > > > >> > > > >>>>> > Dilnaz Amanzholova > > > > >> > > > >> > > > >>>>> > > > > > >> > > > >> > > > >>>>> > > > > >> > > > >> > > > >>>> > > > > >> > > > >> > > > > > > > >> > > > >> > > > > > > >> > > > >> > > > > > > >> > > > >> > > -- > > > > >> > > > >> > > Tatiana Al-Chueyr > > > > >> > > > >> > > > > > > >> > > > >> > > > > > >> > > > >> > > > > >> > > > >> > > > > >> > > > >> -- > > > > >> > > > >> Tatiana Al-Chueyr > > > > >> > > > >> > > > > >> > > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > > > > > > > > > > > >
