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