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 > > > > > > > > > > > > > > >
