Cool :) On Wed, Apr 29, 2026 at 12:53 PM Elad Kalif <[email protected]> wrote:
> yes and I will be happy to work with you on this. > > On Wed, Apr 29, 2026 at 1:47 PM Jarek Potiuk <[email protected]> wrote: > > > 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 > > > > > > > > > > > > > > > > > > > > >
