Ash, I think some clarifications would be beneficial. I did not find anything rude in Vlada's message, it was polite and asking for help. I think responding with aggression is a bad idea especially that we wanted to cooperate with our stewards.
> Also: You work for trillion dollar company. If this is important to Vlada does not work at Google. Vlada works for EPAM and Google hires EPAM to work on many things - like they used to pay Polidea and my team. About 50% of the provider code is Googles. > Google: show us the money. Give us the credits so every PR against the Google PR can run against real GCP resources. This has been offered multiple times in the past; we were the ones unable to consume it. And yes as I understand it, the credits to run all that will happen and are part of this message. And what we miss is wiring running the system tests (not only for Google but for other providers) in the ASF Also just to remind you Ash and everyone. Google is paying me **every single month** - similarly as Astronomer so that I can spend whole my time on Airflow (incluiding the 50% of extra time). They are also platinum sponsors of Airflow Summit. They are already showing the money. The fact that you are not paying attention to those facts does not mean that it is not happening, Ash. Not mentioning the work on AIP-85. You should consider if you are not biased, or if you maybe should pay more attention. And just to be very clear: Vlada did exactly what we call stewards for. She is taking care of issues she sees with maintaining the Google provider. If you look at AIP-95 (Co-created by Vikram, Elad, yourself, Kaxil and me), it mentions a number of metrics (that we actually haven't checked), and it focuses mostly on "Have PRs reviewed and merged" and "Issues handled". Not "Google team must merge them" - but "they are merged". And this happens - partially with Google team support, partially mine, partiall Shahars - and few other people. If you think the Google-hired team isn't doing its job, ideally get those metrics and compare them against other stewards. I recommend basing such discussions on facts rather than personal feelings. And focus on solving issues not how somehow who is not English native puts they words into writing. Be empathetic and try to understand that people might simply come from different cultures and communicate differently - especially in writing. J. On Thu, Oct 8, 2026 at 5:08 PM Ash Berlin-Taylor <[email protected]> wrote: > Hi Ulada, > > You have really, really missed the mark in the tone you used on **your > very first email** to the dev list. > > "We want a clear baseline” - who is “we"? Who are you even? I find this > very rude phrasing, and almost totally blind to how the Airflow community > works. Phrase it as “I would like to propose” and it reads much better. > > Also: You work for trillion dollar company. If this is important to > Google: show us the money. Give us the credits to let every pr to the > Google PR run against real GCP things. > > Thanks, > Ash > > > On 5 Oct 2026, at 14:46, Ulada Zakharava (xWF) <[email protected]> > wrote: > > > > Hi everyone, > > > > We’ve noticed an increasing number of PRs submitted to the Google > Provider > > where contributors—often using AI tooling—don't have access to a GCP > > project to test their changes. > > > > While we love community contributions, many of these PRs touch critical > > logic like authentication, base hooks, or core operator behavior with > only > > mocked unit tests. Maintainers are regularly asked to pull these branches > > and run manual or system tests to see if they actually work against live > > APIs. > > > > Simply put, this doesn't scale. Pulling branches to run ad-hoc system > tests > > takes significant time, and foundational changes often require running > > multiple full suites. Merging without verification isn't an option > either, > > as catching regressions during release candidate testing blocks releases > > and creates painful reverts. > > Proposed Rule > > > > We want to agree on a clear baseline for PRs touching functional or auth > > logic in the Google Provider: > > > > 1. > > > > *Proof of testing required:* Authors must test against a real GCP > > project and include proof (logs, CLI output, or run results) in the PR > > description. > > 2. > > > > *Untested PRs will be put on hold:* Changes affecting runtime behavior > > without evidence of testing shouldn't be reviewed or merged until > validated. > > 3. > > > > *Keep system tests up to date:* New operators or behavior changes > should > > include or update automated system tests, or at minimum show manual > > end-to-end run results. > > > > What we're doing on our end > > > > We understand that not everyone has an active GCP environment. On the > > Google/maintainer side, we’re looking into ways to make it easier to > > trigger specific existing system tests directly on PR branches via CI for > > trusted contributors. Until that workflow is ready, the responsibility of > > proving a change works has to sit with the author. > > > > What do you all think? We'd love to hear feedback before updating the > > provider contribution docs. > > > > Best regards, > > > > Ulada > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
