Hi Ash, You have really, really missed the mark in the tone you used in your public criticism of a fellow Airflow community member who across years contributed dozens of fixes, features, system tests and ongoing provider stewardship.
I think dwelling on the phrasing of non-English-native who works in a good intention and raised real concerns about handling incoming code sets really bad example and is discouraging to many who will read it - is this what **we** want the Airflow Community to be? Best, Michal czw., 8 paź 2026, 17:34 użytkownik Jarek Potiuk <[email protected]> napisał: > 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] > > > > >
