● 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]
>>>>> > > >> >
>>>>> > > >> >
>>>>> > > >>
>>>>> > > >
>>>>> > >
>>>>> >
>>>>>
>>>>

Reply via email to