> is there currently an understanding in the user community, or even Ruff > maintainers, that Ruff rules for Airflow (or any other library for that > matter) are "official" or "officially endorsed"?
Probably not *that* official, but this is closer to how things work today. Whenever Ruff maintainers receive an Airflow PR, they reach out to me (as I've been the most active Ruff contributor for AIR rules in the Airflow PMC) to check our stance on the rule. > Is there precedence for Apache project management procedures being > "organically" extended to independent 3rd party tools? I'm not sure about this. Maybe Jarek has some thoughts? > Does that mean such a rule has no raison d'etre? Not really. It can still make sense. > Will they receive no feedback from contributors associated with Airflow "as > punishment" for not going throughout an approval process they know nothing > about? Will they be advised to follow a different project's (Airflow's) > arbitrary guidelines? I think we should advise them to follow Airflow's guidelines, since the Airflow PMC might be asked to review that PR, and I'd like to ensure we have at least some consensus on how we want to review it. That said, we don't have control over Ruff. Ruff maintainers can still decide to merge a rule and release it without notifying the Airflow PMC. This process is primarily about deciding how we want to respond to those review requests and letting Ruff maintainers know that the Airflow community supports the PR's intent—but whether to merge it is still up to them. And thanks for bringing these up! Best, Wei > On Mar 5, 2026, at 2:21 PM, Dev-iL <[email protected]> wrote: > > Thank you for starting the discussion! > > I don't disagree with anything you said, but let me play the devil's > advocate for a moment. > > I have a fundamental question to bring up - is there currently an > understanding in the user community, or even Ruff maintainers, that Ruff > rules for Airflow (or any other library for that matter) are "official" or > "officially endorsed"? Is there precedence for Apache project management > procedures being "organically" extended to independent 3rd party tools? > > Ruff rules are opt-in, so if a certain user/project disagrees with a > particular rule - they can just disable it. To give a specific example - > say someone creates a rule to migrate from operator api to taskflow - > certain teams will surely not be interested in this and keep it disabled. > Does that mean such a rule has no raison d'etre? > > Regarding the "we" part of your post's title -say a random contributor who > isn't familiar with Airflow's internal procedures proposes a rule (i.e. > raises a PR in Ruff). Will they receive no feedback from contributors > associated with Airflow "as punishment" for not going throughout an > approval process they know nothing about? Will they be advised to > follow a *different > project's* (Airflow's) arbitrary guidelines? > > Would love to hear your thoughts on this! > > Best, > Iliya > > On Thu, 5 Mar 2026, 5:13 Wei Lee, <[email protected]> wrote: > >> Hi everyone, >> >> I'd like to start a discussion on how we decide to submit Airflow-specific >> rules to Ruff in the future. >> >> ## What we have now >> We already have migration rules in place, and this direction was proposed >> by TP quite some time ago. In general, these changes have not required much >> debate because they address cases where behavior no longer works in Airflow >> 3. >> >> While working on the migration, we established a soft convention for rule >> numbering: >> >> **AIR xyz**[1] — where "x" indicates the minimum supported Airflow major >> version (e.g., AIR001 should be applied to all Airflow versions while >> AIR301 works for Airflow 3.0+), "y" means you should do it in "y-1" minor >> version since these things will be deprecated since minor version "y" and >> will be removed in future version (most likely in the next major release, >> but change it as early as possible). (e.g., AIR321 are things changed in >> Airflow 3.1.* but still have backward compatibility) >> >> ## Why this is brought up now >> >> Illya (Dev-iL) recently opened 4 PRs: (Illya even has SKILLS for that!) >> >> - https://github.com/astral-sh/ruff/pull/23584 >> - https://github.com/astral-sh/ruff/pull/23631 >> - https://github.com/astral-sh/ruff/pull/23579 >> - https://github.com/astral-sh/ruff/pull/23583 >> >> The first 2 seem relatively uncontroversial: >> >> - One is already listed in Airflow best practices. >> - One reflects a rule that has already been merged into the Airflow 3 main >> branch. >> >> The latter 2 are best practices. Although we have discussed this in >> https://github.com/apache/airflow/issues/43176, I believe we should have >> a more formal discussion on the dev list. >> >> ## My proposal >> >> For future additions of this type of rule, one possible process could be: >> >> 1. Start a discussion (or Lazy Consensus) on the dev list. If consensus is >> reached, proceed. >> 2. Add the rule to the Airflow best practices documentation; at this >> point, Ruff rule development can proceed in parallel. >> 3. Once merged, update the Ruff rules to the relevant documentation >> accordingly. >> >> Feedback and alternative suggestions are very welcome. If everything >> sounds good, I'll start new threads for those existing PRs. >> >> Thanks! >> >> [1] https://docs.astral.sh/ruff/rules/#airflow-air >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
