Kaxil reviewed and merged it this morning, so I guess we'll see if that did it
or not.
- ferruzzi
From: Amogh Desai
Sent: Tuesday, February 25, 2025 10:11 PM
To: dev@airflow.apache.org
Subject: RE: [EXT] [DISCUSS] Proposal to enhance the PR template
CA
e if it doesn't work.
>
> https://github.com/apache/airflow/pull/47038
>
>
> - ferruzzi
>
>
>
> From: Ferruzzi, Dennis
> Sent: Monday, February 24, 2025 12:23 PM
> To: dev@airflow.apache.org
> Subject: RE: [EXT] [DISCUSS
copied from
> the first such commit found.
>
> ```
>
>
>
>
> - ferruzzi
>
>
>
> From: Jarek Potiuk
> Sent: Sunday, February 23, 2025 11:43 PM
> To: dev@airflow.apache.org
> Subject: RE: [EXT] [DISCUSS] Proposal to enhance the PR template
>
> CAUTION:
e known that by now.
>
>
> - ferruzzi
>
>
>
> From: Jarek Potiuk
> Sent: Monday, February 24, 2025 12:18 PM
> To: dev@airflow.apache.org
> Subject: RE: [EXT] [DISCUSS] Proposal to enhance the PR template
>
> CAUTION: This em
work.
https://github.com/apache/airflow/pull/47038
- ferruzzi
From: Ferruzzi, Dennis
Sent: Monday, February 24, 2025 12:23 PM
To: dev@airflow.apache.org
Subject: RE: [EXT] [DISCUSS] Proposal to enhance the PR template
CAUTION: This email originated from outside of
tiuk
Sent: Monday, February 24, 2025 12:18 PM
To: dev@airflow.apache.org
Subject: RE: [EXT] [DISCUSS] Proposal to enhance the PR template
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
conte
bject: RE: [EXT] [DISCUSS] Proposal to enhance the PR template
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 exter
One small thing though.. Currently boring cyborg usefulness is limited
because we have to manually "approve the workflows" that boring cyborg
runs. So might be a good opportunity to look how we can fix it, the problem
is that the boring cyborg is seen as a user who never committed anything to
our r
> based on what has changed. I need to take a look at how this can be done.
This should be very easy with boring-cyborg. What we **really** need to
make sure though is that our code is structured in the way that when we
select "paths" it nicely identifies the "impact". And rather than trying to
fi
Thanks all for your responses.
> Perhaps instead of a checkbox we could auto-add a label that indicates
which API is being touched, based on which subfolder of api_fastapi. This
might be a better way to help meet your aim of helping with tracking down
changes, that isn't reliant on humans checkin
Yep, I also think better labeling (and other CI checks) would be a better
choice! (if we could and have the bandwidth to do so) Checkboxes often get
overlooked, and might need some time to teach all contributors. Take the
significant template as an example, I still need to check new newsfragment
I like much more "fixing" (or upgrading) the labelling scheme rather than
checkbox. With changes like that we have to be careful to impact experience
of everyone - while improving some "failure" scenario, you also make live
of everyone who raises PR and has to learn about those checkboxes, know
wha
RE
>I think this small change would significantly improve the confidence in
code reviewers during review and also make it easier to track down issues
if they arise at a later stage.
So, expanding... any time you see a change to airflow/api_fastapi, you are
probably making changes to "the interface
It feels more like a failure of CI / testing than a failure of PR
description.
Is an author supposed to exercise all APIs for every "public interface"
change?
On Fri, Feb 21, 2025 at 8:52 AM Ankit Chaurasia wrote:
> Hi Amogh,
>
> Great idea! I agree with adding a checkbox for public interface c
Hi Amogh,
Great idea! I agree with adding a checkbox for public interface changes in
the PR template. Additionally, I suggest we add a brief section where
contributors can note any potential side effects or impacts if known. This
extra step could help reviewers catch issues early.
Additionally, t
Hello Everyone,
I have noticed an increased number of PRs introducing changes to the public
interfaces of Airflow (UI / API / CLI) do not provide sufficient
information / evidence about their working, either in form of screenshots
(for UI mainly) and/or API responses.
For example, a recent PR mer
16 matches
Mail list logo
