Super cool! Didn't expect it to be there this quickly! Thanks Jarek! Jarek Potiuk <[email protected]> 於 2026年3月20日週五 下午7:12寫道：
> ● The label needs to be created on the GitHub repo itself. Since this is > apache/airflow and I shouldn't make changes to the upstream repo directly, > I'll note this for the user. > > > > On Fri, Mar 20, 2026 at 12:11 PM Jarek Potiuk <[email protected]> wrote: > > > Here's what I changed in > > .github/workflows/check-newsfragment-pr-number.yml: > > > > > > > > > > > > > > > > > > 1. Added labeled and unlabeled to PR event types (line 27) — so the > > workflow re-evaluates when labels are added or removed. > > > > > > > > 2. Added if condition on the job (line 39) — if: ${{ > > !contains(github.event.pull_request.labels.*.name, 'skip newsfragment > > check') }} skips the entire job when the PR has the skip newsfragment > check > > label. > > > > > > > > > > > > > > To complete the setup, the label needs to be created on the GitHub > repo: > > > > > > > > > > > > > > > > > > > > gh label create "skip newsfragment check" --repo apache/airflow > > --description "Skip the newsfragment PR number check" --color "ededed" > > > > > > > > > > > > > > > > > > You'll need appropriate permissions on the apache/airflow repo to > create > > the label. When the label is applied to a PR, the workflow job will be > > skipped entirely (it will show as "Skipped" in the checks). > > > > On Fri, Mar 20, 2026 at 12:10 PM Jarek Potiuk <[email protected]> wrote: > > > >> Funny thing: Claude—that 100% created that PR in minutes after my two > >> prompts (add it, add the docs) even refused to create the label (just > >> explained it to me how to do it) - because we ask it in the AGENTS.md to > >> never push things upstream. Good bot, nice bot. Listens to what we ask > it > >> to do. > >> > >> On Fri, Mar 20, 2026 at 12:07 PM Jarek Potiuk <[email protected]> wrote: > >> > >>> And of course label created. TIL: > >>> > >>> > gh label create "skip newsfragment check" --repo apache/airflow > >>> --description "Skip the newsfragment PR number check" --color "ededed" > >>> ✓ Label "skip newsfragment check" created in apache/airflow > >>> > >>> J. > >>> > >>> On Fri, Mar 20, 2026 at 12:04 PM Jarek Potiuk <[email protected]> > wrote: > >>> > >>>> https://github.com/apache/airflow/pull/63983 -> adds skipping, > updates > >>>> docs and informs the author that they can skip the check by setting > the > >>>> label. > >>>> > >>>> On Fri, Mar 20, 2026 at 11:37 AM Wei Lee <[email protected]> wrote: > >>>> > >>>>> > I think there are a lot of nuances between "remove" and "leave"—and > >>>>> that > >>>>> is a good example of that. > >>>>> > >>>>> I feel changing is more toward the "leave" decision 🤔, but yep, we > can > >>>>> definitely find some middle ground. Then I'll keep this discussion > >>>>> open a > >>>>> bit longer and see whether we can have a consensus 🙂 > >>>>> > >>>>> > We can always follow the procedure we use for > all checks: require > >>>>> the > >>>>> "skip > >>>>> > newsfragment check" label to be set. We can just follow what we do > >>>>> in 10 > >>>>> > other similar cases. > >>>>> > >>>>> Yep, sounds good 👍 I can work on that next week. But if anyone’s > >>>>> interested in adding it before me. Feel free to do so 🙂 > >>>>> > >>>>> Jarek Potiuk <[email protected]> 於 2026年3月20日週五 下午6:23寫道： > >>>>> > >>>>> > > A separate but related topic. How should we do if we did not add > >>>>> the > >>>>> > newsfragment back to the time the change was made? If we create a > >>>>> follow-up > >>>>> > PR for that, then we won't pass the CI check. Or should we just use > >>>>> the > >>>>> > number of the follow-up PR? > >>>>> > > >>>>> > We can always follow the procedure we use for all checks: require > >>>>> the "skip > >>>>> > newsfragment check" label to be set. We can just follow what we do > >>>>> in 10 > >>>>> > other similar cases. > >>>>> > > >>>>> > J,. > >>>>> > > >>>>> > > >>>>> > On Fri, Mar 20, 2026 at 11:14 AM Wei Lee <[email protected]> > >>>>> wrote: > >>>>> > > >>>>> > > A separate but related topic. How should we do if we did not add > >>>>> the > >>>>> > > newsfragment back to the time the change was made? If we create a > >>>>> > follow-up > >>>>> > > PR for that, then we won't pass the CI check. Or should we just > >>>>> use the > >>>>> > > number of the follow-up PR? > >>>>> > > > >>>>> > > Wei Lee <[email protected]> 於 2026年3月20日週五 下午6:06寫道： > >>>>> > > > >>>>> > > > It seems we don't have a strong consensus on this issue. If no > >>>>> one > >>>>> > feels > >>>>> > > > strongly about whether we should keep it or remove it, and no > >>>>> one can > >>>>> > > > propose a compelling argument to persuade the other side, I > will > >>>>> put > >>>>> > this > >>>>> > > > matter to a vote. > >>>>> > > > > >>>>> > > > I initiated this discussion because it no longer serves my > >>>>> original > >>>>> > > > purpose. However, I'm okay if it still proves useful. I believe > >>>>> this is > >>>>> > > > more of a decision for release managers. (I guess these files > >>>>> are not > >>>>> > > used > >>>>> > > > elsewhere?) > >>>>> > > > > >>>>> > > > Kaxil Naik <[email protected]> 於 2026年3月18日週三 上午2:03寫道： > >>>>> > > > > >>>>> > > >> I'd be for removing the checkmark needed at the bottom. In > >>>>> recent > >>>>> > > releases > >>>>> > > >> I did, most of the things were touching more than one anyway > >>>>> and what > >>>>> > > went > >>>>> > > >> on actual release notes had nothing to do with the "type" > >>>>> > > >> > >>>>> > > >> **Types of change** > >>>>> > > >> > >>>>> > > >> - [ ] DAG changes > >>>>> > > >> - [ ] Config changes > >>>>> > > >> - [ ] API changes > >>>>> > > >> - [ ] CLI changes > >>>>> > > >> - [ ] Behaviour changes > >>>>> > > >> - [ ] Plugin changes > >>>>> > > >> - [ ] Dependency changes > >>>>> > > >> > >>>>> > > >> On Tue, 17 Mar 2026 at 09:59, Jarek Potiuk <[email protected]> > >>>>> wrote: > >>>>> > > >> > >>>>> > > >> > Yeah. The format is cool - we might consider adding or > >>>>> removing some > >>>>> > > >> > areas - but I think it's a good setup + automation. > >>>>> > > >> > > >>>>> > > >> > J. > >>>>> > > >> > > >>>>> > > >> > On Tue, Mar 17, 2026 at 8:24 AM Ephraim Anierobi > >>>>> > > >> > <[email protected]> wrote: > >>>>> > > >> > > > >>>>> > > >> > > I’m on the same page as Wei about removing the format > check. > >>>>> > > >> > > > >>>>> > > >> > > For our uses now, requiring a title and description is > >>>>> enough to > >>>>> > > >> capture > >>>>> > > >> > > significant changes. > >>>>> > > >> > > > >>>>> > > >> > > - Ephraim > >>>>> > > >> > > > >>>>> > > >> > > On Tue, 17 Mar 2026 at 08:07, Amogh Desai < > >>>>> [email protected]> > >>>>> > > >> wrote: > >>>>> > > >> > > > >>>>> > > >> > > > Yes, I still think we should continue using the format. > >>>>> > > >> > > > > >>>>> > > >> > > > Thanks & Regards, > >>>>> > > >> > > > Amogh Desai > >>>>> > > >> > > > > >>>>> > > >> > > > > >>>>> > > >> > > > On Tue, Mar 17, 2026 at 11:59 AM Wei Lee < > >>>>> [email protected]> > >>>>> > > >> wrote: > >>>>> > > >> > > > > >>>>> > > >> > > > > I think I didn't phrase it very clearly 🤦♂️ What I > >>>>> meant is > >>>>> > > that > >>>>> > > >> > this > >>>>> > > >> > > > is > >>>>> > > >> > > > > the format check for significant news fragments: > >>>>> > > >> > > > > > >>>>> > > >> > > > > **Types of change** > >>>>> > > >> > > > > > >>>>> > > >> > > > > - [ ] DAG changes > >>>>> > > >> > > > > - [ ] Config changes > >>>>> > > >> > > > > - [ ] API changes > >>>>> > > >> > > > > - [ ] CLI changes > >>>>> > > >> > > > > - [ ] Behaviour changes > >>>>> > > >> > > > > - [ ] Plugin changes > >>>>> > > >> > > > > - [ ] Dependency changes > >>>>> > > >> > > > > > >>>>> > > >> > > > > I also think we should continue to keep significant > news > >>>>> > > >> fragments — > >>>>> > > >> > I > >>>>> > > >> > > > > just wanted to confirm that we still want to use this > >>>>> format. > >>>>> > > >> > > > > > >>>>> > > >> > > > > Best, > >>>>> > > >> > > > > Wei > >>>>> > > >> > > > > > >>>>> > > >> > > > > > On Mar 17, 2026, at 1:44 PM, Amogh Desai < > >>>>> > > [email protected] > >>>>> > > >> > > >>>>> > > >> > > > wrote: > >>>>> > > >> > > > > > > >>>>> > > >> > > > > > I am in favour of keeping it. It helps in issuing > news > >>>>> > > fragments > >>>>> > > >> > with > >>>>> > > >> > > > > > structure. > >>>>> > > >> > > > > > > >>>>> > > >> > > > > > Thanks & Regards, > >>>>> > > >> > > > > > Amogh Desai > >>>>> > > >> > > > > > > >>>>> > > >> > > > > > > >>>>> > > >> > > > > > On Tue, Mar 17, 2026 at 11:11 AM Rahul Vats < > >>>>> > > >> > [email protected]> > >>>>> > > >> > > > > wrote: > >>>>> > > >> > > > > > > >>>>> > > >> > > > > >> +1 We should keep significant news fragments. > >>>>> > > >> > > > > >> > >>>>> > > >> > > > > >> Regards, > >>>>> > > >> > > > > >> Rahul Vats > >>>>> > > >> > > > > >> > >>>>> > > >> > > > > >> > >>>>> > > >> > > > > >> > >>>>> > > >> > > > > >> On Tue, 17 Mar 2026 at 07:54, Zhe-You(Jason) Liu < > >>>>> > > >> > [email protected] > >>>>> > > >> > > > > > >>>>> > > >> > > > > >> wrote: > >>>>> > > >> > > > > >> > >>>>> > > >> > > > > >>> I agree with Jarek and Ferruzzi about keeping the > >>>>> > > significant > >>>>> > > >> > news > >>>>> > > >> > > > > >>> fragment. > >>>>> > > >> > > > > >>> > >>>>> > > >> > > > > >>> From my perspective, the news fragment serves a > >>>>> similar > >>>>> > role > >>>>> > > >> to > >>>>> > > >> > ADRs > >>>>> > > >> > > > > >>> (Architectural Decision Records), providing an > >>>>> explicit > >>>>> > way > >>>>> > > to > >>>>> > > >> > record > >>>>> > > >> > > > > >> major > >>>>> > > >> > > > > >>> discussions and behavior changes. We have ADRs for > >>>>> Breeze > >>>>> > > >> [1], so > >>>>> > > >> > > > > keeping > >>>>> > > >> > > > > >>> those news fragments as ADR-like records for > >>>>> Airflow Core > >>>>> > > >> would > >>>>> > > >> > be a > >>>>> > > >> > > > > nice > >>>>> > > >> > > > > >>> way to help the repo track its decision history. > >>>>> > > >> > > > > >>> > >>>>> > > >> > > > > >>> [1] > >>>>> > > >> > > >>>>> https://github.com/apache/airflow/tree/main/dev/breeze/doc/adr > >>>>> > > >> > > > > >>> > >>>>> > > >> > > > > >>> Best, > >>>>> > > >> > > > > >>> Jason > >>>>> > > >> > > > > >>> > >>>>> > > >> > > > > >>> On Tue, Mar 17, 2026 at 9:12 AM Ferruzzi, Dennis < > >>>>> > > >> > > > [email protected]> > >>>>> > > >> > > > > >>> wrote: > >>>>> > > >> > > > > >>> > >>>>> > > >> > > > > >>>> Personally I like it for major updates and > >>>>> features. > >>>>> > > >> > > > > >>>> ________________________________ > >>>>> > > >> > > > > >>>> From: Jarek Potiuk <[email protected]> > >>>>> > > >> > > > > >>>> Sent: Monday, March 16, 2026 4:00 AM > >>>>> > > >> > > > > >>>> To: [email protected] < > [email protected] > >>>>> > > >>>>> > > >> > > > > >>>> Subject: RE: [EXT] [DISCUSS] Do we still need the > >>>>> > > significant > >>>>> > > >> > > > > >>> newsfragment > >>>>> > > >> > > > > >>>> check introduced in #44378? > >>>>> > > >> > > > > >>>> > >>>>> > > >> > > > > >>>> CAUTION: This email originated from outside of > the > >>>>> > > >> > organization. Do > >>>>> > > >> > > > > not > >>>>> > > >> > > > > >>>> click links or open attachments unless you can > >>>>> confirm > >>>>> > the > >>>>> > > >> > sender > >>>>> > > >> > > > and > >>>>> > > >> > > > > >>> know > >>>>> > > >> > > > > >>>> the content is safe. > >>>>> > > >> > > > > >>>> > >>>>> > > >> > > > > >>>> > >>>>> > > >> > > > > >>>> > >>>>> > > >> > > > > >>>> AVERTISSEMENT: Ce courrier électronique provient > >>>>> d’un > >>>>> > > >> expéditeur > >>>>> > > >> > > > > >> externe. > >>>>> > > >> > > > > >>>> Ne cliquez sur aucun lien et n’ouvrez aucune > pièce > >>>>> jointe > >>>>> > > si > >>>>> > > >> > vous ne > >>>>> > > >> > > > > >>> pouvez > >>>>> > > >> > > > > >>>> pas confirmer l’identité de l’expéditeur et si > vous > >>>>> > n’êtes > >>>>> > > >> pas > >>>>> > > >> > > > certain > >>>>> > > >> > > > > >>> que > >>>>> > > >> > > > > >>>> le contenu ne présente aucun risque. > >>>>> > > >> > > > > >>>> > >>>>> > > >> > > > > >>>> > >>>>> > > >> > > > > >>>> > >>>>> > > >> > > > > >>>> I think it's still quite useful > >>>>> > > >> > > > > >>>> > >>>>> > > >> > > > > >>>> On Mon, Mar 16, 2026 at 11:48 AM Wei Lee < > >>>>> > > >> [email protected]> > >>>>> > > >> > > > wrote: > >>>>> > > >> > > > > >>>>> > >>>>> > > >> > > > > >>>>> Hi all, > >>>>> > > >> > > > > >>>>> > >>>>> > > >> > > > > >>>>> The significant newsfragment check was > introduced > >>>>> in > >>>>> > > #44378 > >>>>> > > >> [1] > >>>>> > > >> > > > > >> mainly > >>>>> > > >> > > > > >>>> to support the Airflow 2 to 3 migration and track > >>>>> > breaking > >>>>> > > >> > changes. > >>>>> > > >> > > > (I > >>>>> > > >> > > > > >>>> thought we only added significant newsfragments > for > >>>>> > > breaking > >>>>> > > >> > changes > >>>>> > > >> > > > > >> back > >>>>> > > >> > > > > >>>> then, but Jed corrected me sometime after that.) > >>>>> > > >> > > > > >>>>> > >>>>> > > >> > > > > >>>>> Now that Airflow 3 is out, do we still need it? > >>>>> Or maybe > >>>>> > > we > >>>>> > > >> can > >>>>> > > >> > > > just > >>>>> > > >> > > > > >>>> remove it. > >>>>> > > >> > > > > >>>>> > >>>>> > > >> > > > > >>>>> Best, > >>>>> > > >> > > > > >>>>> Wei Lee > >>>>> > > >> > > > > >>>>> > >>>>> > > >> > > > > >>>>> [1] > https://github.com/apache/airflow/pull/44378 > >>>>> > > >> > > > > >>>>> > >>>>> > > >> > > > > >>>>> > > >> > >>>>> --------------------------------------------------------------------- > >>>>> > > >> > > > > >>>>> 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] > >>>>> > > >> > > > > >>>> > >>>>> > > >> > > > > >>>> > >>>>> > > >> > > > > >>> > >>>>> > > >> > > > > >> > >>>>> > > >> > > > > > >>>>> > > >> > > > > > >>>>> > > >> > > > > > >>>>> > > >> > >>>>> --------------------------------------------------------------------- > >>>>> > > >> > > > > 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] > >>>>> > > >> > > >>>>> > > >> > > >>>>> > > >> > >>>>> > > > > >>>>> > > > >>>>> > > >>>>> > >>>> >
