Hi Elad, To clarify, I do not see my suggestions as blockers to your proposal. My point is that simplifying the acceptance process naturally increases the priority of implementing the planned tooling and clarifying steward responsibilities.
If we simplify the process and accelerate new provider acceptance, we must also speed up the completion of the surrounding governance framework. Furthermore, I will actively work on accelerating this tooling once we agree on the simplification. I hope that clarifies my point. Best, Jarek Potiuk On Wed, Apr 29, 2026 at 12:13 PM Elad Kalif <[email protected]> wrote: > Jarek I agree with the sentiment but I don't think this should be part of > this proposal. > You are binding the approval process with code review process and > ownership/governance about the code. This proposal does not change anything > about the ownership/governance model. > The approval process of vote/lazy consensus was established in an era where > we could not handle so many providers easily, thus we wanted to limit the > number of official providers and to discuss the question "Should this be a > provider owned by airflow or owned by 3rd party". That question is no > longer a serious concern thus I wish to simplify the policy around it. That > is it. > > > If we automate checks for at least two people in CODESTEWARDS and ensure > they are automatically assigned as reviewers and CC'ed on related issues, I > am happy to drop the vote requirement. Given the effort required for > integrations like Akeyless and Vespa, our existing quality gates should > sufficiently prevent "drive-by" providers. > > I don't think this is a blocker to my proposal. That is something that can > happen in parallel. > The vote/lazy consensus part that I ask to drop does not offer any value on > that front so whether we accept this proposal or not it will not change > anything about the automation you are suggesting. > > On Tue, Apr 28, 2026 at 5:44 PM Jarek Potiuk <[email protected]> wrote: > > > > I do support Jarek's suggestion for automation of checks when possible, > > but > > it shouldn't be blocker IMO for introducing the suggested changes. > > > > Side comment. Those things are no longer blockers. > > > > To be honest, nowadays, automating a process like that (if we agree on > it) > > is > > literally one, good prompt away. We just need to know what to prompt and > be > > ready > > to step in while the agent implements it. > > > > Once we agree on the process, it will generally work by pointing the > Agent > > to this discussion and asking the agent: > > > > "Implement changes in the Airflow CI and breeze following the discussion > in > > <link to the discussion>." > > > > Iterate a little, answer a few questions and correct the agent if it goes > > sideways > > here and there. > > > > What results is a ready PR implementing the process - ready for review, > > with all the docs and > > explanation. We just need to agree on the process first. > > > > And I am not joking at all - this is what I've been literally doing for > the > > last two months. Most > > of my PRs are now done like that. > > > > I will be happy to do it once the discussion concludes and show you the > > results and prompts > > used :) > > > > J. > > > > > > > > On Tue, Apr 28, 2026 at 2:56 PM Shahar Epstein <[email protected]> > wrote: > > > > > +1 from me for this suggestion, which will help reducing beaurocracy > and > > > inviting more providers to get onboarded. > > > > > > One suggestion, though: > > > To avoid ambiguity, I think that the "without formal vote" should be > > > replaced with "with the support of at least one sponsored committer" - > > > explicitly stating that there should be a committer "in charge" (which > > > could be technically considered as a "vote", providing some level of > > > formality...). > > > > > > I do support Jarek's suggestion for automation of checks when possible, > > but > > > it shouldn't be blocker IMO for introducing the suggested changes. > > > > > > > > > Shahar > > > > > > > > > On Tue, Apr 28, 2026, 12:42 Elad Kalif <[email protected]> wrote: > > > > > > > Hi, > > > > > > > > I'd like to propose a small but meaningful change to how we accept > new > > > > community providers. > > > > > > > > Background > > > > ---------- > > > > > > > > When the original acceptance process was written, the bar for what > > > > qualified as a > > > > community provider was higher and more subjective, a formal vote made > > > sense > > > > as a > > > > gate to ensure broad consensus before investing in a new integration. > > > > AIP-95 changed that calculus. By introducing the Incubation stage > with > > > > clear, objective > > > > health metrics and a defined graduation path, we already have a > > > structured > > > > safety net. > > > > A provider that doesn't meet the bar will not graduate; one that does > > has > > > > already proven > > > > its value. The vote before acceptance was largely redundant with the > > > > governance framework > > > > AIP-95 put in place. > > > > > > > > Proposed change > > > > --------------- > > > > > > > > Drop the [VOTE] (and the [LAZY CONSENSUS] shortcut) from the > acceptance > > > > process. > > > > A [DISCUSS] thread on the devlist open for 7 days is sufficient. If > no > > > > objections > > > > are raised, the proposal is considered accepted and the contributor > can > > > > open a PR. > > > > > > > > The prerequisites remain unchanged: working codebase, at least two > > > > stewards, a sponsoring > > > > committer, and quality standards. We're also making system test > > coverage > > > an > > > > explicit > > > > consideration in the proposal, which was implicit before. > > > > > > > > This keeps the community informed and gives everyone a chance to > raise > > > > concerns, without > > > > creating unnecessary bureaucratic friction for contributors. > > > > > > > > The corresponding docs update is here: > > > > https://github.com/apache/airflow/pull/66010 > > > > > > > > Happy to hear thoughts. > > > > Elad > > > > > > > > > >
