Relax note about rebase/merge

[jscheffl]

We have a very high pace in development at the moment, with the automated PR triage we made a note so far if the PR is not on laest main... but with ~20 PRs/day I think it is hard to keep-up and we do not want to enforce every contributor to always rebase for a few commits of diff.

I think it is reasonable to relax the note to rebase a bit to ~2 days, therefore proposing a threshold of 50 commits behind main before not is presented. Any other number is also fine but we should keep in mind there are "normal" people contributing who are not rebasing 24/7.

---

Was generative AI tooling used to co-author this PR?

• Yes (please specify the tool below)

---

• Read the Pull Request Guidelines for more information. Note: commit author/co-author name and email in commits become permanently public when merged.
• For fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
• When adding dependency, check compliance with the ASF 3rd Party License Policy.
• For significant user-facing changes create newsfragment: {pr_number}.significant.rst, in airflow-core/newsfragments. You can add this file in a follow-up commit after the PR is created so you know the PR number.

[potiuk]

The idea here was to make people rebase in case not being rebased is causing their issue - sometimes when we have a broken main, just rebasing by 2 or 3 commits makes it works, and people are not even trying to do it.

I am fine with changing this message - but maybe we should still post it when the number is low and there is a static check failing - and then change the description telling that "If you do not think that error is cause by you, you are N comits behind mine, so you might attempt to rebase your PR to see if it fixes your problem" (or something like that).

[jscheffl]

The idea here was to make people rebase in case not being rebased is causing their issue - sometimes when we have a broken main, just rebasing by 2 or 3 commits makes it works, and people are not even trying to do it.

I am fine with changing this message - but maybe we should still post it when the number is low and there is a static check failing - and then change the description telling that "If you do not think that error is cause by you, you are N comits behind mine, so you might attempt to rebase your PR to see if it fixes your problem" (or something like that).

Good point. Would merge it now and feell free to improve in another iteration/follow up PR!

[github-actions]

Backport failed to create: v3-1-test. View the failure log Run details

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status	Branch	Result
❌	v3-1-test

You can attempt to backport this manually by running:

cherry_picker 67ec955 v3-1-test

This should apply the commit to the v3-1-test branch and leave the commit in conflict state marking
the files that need manual conflict resolution.

After you have resolved the conflicts, you can continue the backport process by running:

cherry_picker --continue

If you don't have cherry-picker installed, see the installation guide.