FYI, I changed my mind about auto-merging. In the last couple of days I merged many PRs quickly when they were still running because I "knew" they were ok. It would be huge impact if I had to wait for all of them to succeed. I think now that the marginal improvement in "focus" when reviewing the PRs is not worth it.
On Thu, May 1, 2025 at 11:38 AM Kaxil Naik <kaxiln...@gmail.com> wrote: > That's what I was saying. But welcoming discussion or feedback and then > terming it negative is a no-go, Jarek. > > > > On Thu, 1 May 2025 at 15:07, Jarek Potiuk <ja...@potiuk.com> wrote: > > > I propose - let's not be defensive or offensive, but try to hear each > other > > and improve things in the future :). > > > > On Thu, May 1, 2025 at 11:35 AM Kaxil Naik <kaxiln...@gmail.com> wrote: > > > > > >But I would personally love to see more "yes, but" than "no". > > > > > > Saying "would love to hear what you think" in the original message > > followed > > > by terming "negative" is not the way to collaborate. > > > > > > On Thu, 1 May 2025 at 15:01, Kaxil Naik <kaxiln...@gmail.com> wrote: > > > > > > > "-1" was backed with rationale discussion and no one has said it was > a > > > bad > > > > idea but you have said it is "negative". > > > > > > > > On Thu, 1 May 2025 at 14:59, Jarek Potiuk <ja...@potiuk.com> wrote: > > > > > > > >> > That said, I want to push back on the framing of some feedback as > > > >> “negative.” I really appreciate the folks who raised concerns, those > > > >> perspectives are vital to making the project stronger and more > > > inclusive. > > > >> > > > >> I think what I wanted to say is that I think we should all exercise > > > >> empathy. It's super easy to say "-1" but it's harder to say "It's a > > good > > > >> idea but ..". Psychological effect of the "-1" is that it "cuts the > > > wings" > > > >> of the person who has some idea and wants to follow it through. The > > > >> psychological effect of "cool idea, but" is that it - more often > than > > > not > > > >> - > > > >> make the person more energised and inspired to look for a better > > > solution. > > > >> > > > >> And yes I know different people have different communication style, > > and > > > >> there are cultural differences and all that. But I would personally > > love > > > >> to > > > >> see more "yes, but" than "no". > > > >> > > > >> That's all I want to say.. > > > >> > > > >> J/ > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> On Thu, May 1, 2025 at 11:23 AM Kaxil Naik <kaxiln...@gmail.com> > > wrote: > > > >> > > > >> > Thanks for the energy and initiative here. > > > >> > > > > >> > That said, I want to push back on the framing of some feedback as > > > >> > “negative.” I really appreciate the folks who raised concerns, > those > > > >> > perspectives are vital to making the project stronger and more > > > >> inclusive. > > > >> > > > > >> > Let’s make sure we continue to welcome both enthusiasm and > critique. > > > As > > > >> > the ASF > > > >> > Code of Conduct < > https://www.apache.org/foundation/policies/conduct > > > > > > >> > reminds us, thoughtful disagreement and diverse viewpoints are not > > > only > > > >> > expected but encouraged. Referring to concerns as “negative”, even > > > >> > unintentionally, can discourage people from speaking up, which we > > want > > > >> to > > > >> > avoid. > > > >> > > > > >> > We all want what’s best for Airflow, and part of that is making > sure > > > >> > everyone feels safe to contribute, especially when something > doesn’t > > > >> feel > > > >> > right. > > > >> > > > > >> > >Rather than focusing on the negative side, try to figure out a > way > > to > > > >> make > > > >> > it work :) > > > >> > > > > >> > Back to the proposal from Jens and you - Yes that (a comment > > allowing > > > >> to > > > >> > still merge/auto-merge the PR) alleviates my concern. > > > >> > > > > >> > Regards, > > > >> > Kaxil > > > >> > > > > >> > > > > >> > > > > >> > On Thu, 1 May 2025 at 12:54, Jarek Potiuk <ja...@potiuk.com> > wrote: > > > >> > > > > >> > > I really like Jens's line of thought. Rather than focusing on > the > > > >> > negative > > > >> > > side, try to figure out a way to make it work :). That's very > > > >> inspiring. > > > >> > > > > > >> > > I think the original slack proposal of Jens was rather brittle, > > but > > > it > > > >> > made > > > >> > > me think that we can actually implement what we need rather > > quickly. > > > >> > > > > > >> > > Following the `Dependabot` style @rebase - we could implement - > > very > > > >> > easily > > > >> > > - there are ready actions for that and other projects like > apache > > > beam > > > >> > are > > > >> > > using similar workflows - the comment workflow, where maintainer > > who > > > >> > wants > > > >> > > to merge (or auto-merge) such "failing" PR would just comment > it > > > >> > > appropriately. > > > >> > > > > > >> > > What we really want is to make the "finalize" check succeed, so > if > > > >> the PR > > > >> > > misses the "Finalize" step, a committer would just have to > comment > > > it > > > >> > with > > > >> > > "@bypass-finalize` or `@finalize` or similar. And what it would > > do, > > > it > > > >> > > would use Github API to make the "Finalize" check succeed. There > > is > > > an > > > >> > API > > > >> > > for that. > > > >> > > > > > >> > > That has a few nice properties: > > > >> > > > > > >> > > * it uses the same GitHub UI we use, no need to have an "escape > > > hatch" > > > >> > and > > > >> > > separate remote > > > >> > > * it follows the pattern we already agreed to some time ago and > > > >> generally > > > >> > > follow -> we are supposed (as maintainers) to explain when we > are > > > >> merging > > > >> > > such failing PR to show that this is a deliberate action - I > > usually > > > >> for > > > >> > > example always add "fixed already in main" or "Fixed already by > > > #..." > > > >> > > comment - you really need a comment in this case explaining that > > it > > > >> was > > > >> > not > > > >> > > accidental "merge". > > > >> > > * so if we have such workflow, it would "force" maintainer to > > make a > > > >> > > deliberate decision "yes I want to merge it despite failing" and > > > make > > > >> a > > > >> > > comment in the PR > > > >> > > * it would only set the "finalize" check to succeed, so still > you > > > >> would > > > >> > not > > > >> > > be able to merge it without having an approval - this would only > > > >> bypass > > > >> > the > > > >> > > "finalize" check > > > >> > > > > > >> > > WDYT? Would that address all concerns with auto-merge ? Does it > > make > > > >> > sense > > > >> > > and is it "easy enough" to follow? Or are there any other > > concerns? > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > On Wed, Apr 30, 2025 at 10:36 PM Pavankumar Gopidesu < > > > >> > > gopidesupa...@gmail.com> wrote: > > > >> > > > > > >> > > > I am also in line with Jens. The auto-merge feature works well > > in > > > >> > keeping > > > >> > > > the CI pipeline green before merging. > > > >> > > > However, there are situations where we need to merge changes > > > >> quickly. > > > >> > > > Instead of using an > > > >> > > > escape route (which I’m not a fan of, as it carries risks if > > > >> something > > > >> > > goes > > > >> > > > wrong—even though we can revert, it’s still a concern), > > > >> > > > we could explore ways to dynamically bypass certain checks > when > > > >> > necessary > > > >> > > > or maybe some help from INFRA? > > > >> > > > > > > >> > > > Pavan > > > >> > > > > > > >> > > > On Wed, Apr 30, 2025 at 9:22 PM Jens Scheffler > > > >> > > <j_scheff...@gmx.de.invalid > > > >> > > > > > > > >> > > > wrote: > > > >> > > > > > > >> > > > > As there was a call for more opinions. Here I am :-D > > > >> > > > > > > > >> > > > > I understand both positions. As I like AutoMerge very much I > > am > > > >> not > > > >> > > > > giving up :-D I'd like to keep it. > > > >> > > > > > > > >> > > > > I think there is still an option in between. Maybe need to > > > draft a > > > >> > bit > > > >> > > > > of thoughts but I think we could build something still > around > > > the > > > >> > > > > limitations allowing automation. > > > >> > > > > > > > >> > > > > Added a minor thought to the slack chat. But if community > > rules > > > >> > propose > > > >> > > > > to push to devchennel let me know. > > > >> > > > > > > > >> > > > > Jens > > > >> > > > > > > > >> > > > > On 30.04.25 11:04, Jarek Potiuk wrote: > > > >> > > > > > Yeah, And I would encourage everyone to try it and provide > > > >> feedback > > > >> > > > while > > > >> > > > > > it is enabled. > > > >> > > > > > > > > >> > > > > > So far we identified a few things (and fix them) that made > > it > > > >> > > > borderline > > > >> > > > > > unusable (bug in workflow for UI-only changes, GitHub > > starting > > > >> to > > > >> > > > 429-us > > > >> > > > > > with too many requests, and the mysterious "hanging" of > the > > > >> latest > > > >> > > > > > botocore/celery (?) "special tests" -> all that is already > > > >> > addressed > > > >> > > in > > > >> > > > > > main, and those issues should not happen (hopefully), so > I'd > > > >> say we > > > >> > > can > > > >> > > > > now > > > >> > > > > > "truly" see how it might work. > > > >> > > > > > > > > >> > > > > > And one comment from my side - indeed, I find it nice > > > actually, > > > >> but > > > >> > > > it's > > > >> > > > > > definitely not a "deal breaker"- so if others find it too > > > >> > > disruptive, I > > > >> > > > > am > > > >> > > > > > definitely not going to die on this hill, I just thought > it > > > does > > > >> > > > improve > > > >> > > > > > the workflow in the way that it allows for mostly "fire > and > > > >> forget" > > > >> > > > when > > > >> > > > > > you approve the workflow, one thing that it definitely > > > improves > > > >> is > > > >> > > that > > > >> > > > > you > > > >> > > > > > do not have to remember about coming back to merge a > request > > > >> when > > > >> > CI > > > >> > > > > > succeeds. > > > >> > > > > > > > > >> > > > > > J. > > > >> > > > > > > > > >> > > > > > On Wed, Apr 30, 2025 at 10:58 AM Kaxil Naik < > > > >> kaxiln...@gmail.com> > > > >> > > > wrote: > > > >> > > > > > > > > >> > > > > >> Forgot to note an additional point in Summary: If we find > > > >> anything > > > >> > > > > blocking > > > >> > > > > >> us in that period, we will merge > > > >> > > > > >> https://github.com/apache/airflow/pull/50009 to disable > > > >> > auto-merge. > > > >> > > > > >> > > > >> > > > > >> On Wed, 30 Apr 2025 at 14:26, Kaxil Naik < > > > kaxiln...@gmail.com> > > > >> > > wrote: > > > >> > > > > >> > > > >> > > > > >>> Jarek & I discussed it on Slack in > > #internal-airflow-ci-cd. > > > >> > Summary > > > >> > > > > >> below: > > > >> > > > > >>> I have a PR to disable it: > > > >> > > > > https://github.com/apache/airflow/pull/50009. > > > >> > > > > >>> However, given that many countries will be on holiday on > > > May 1 > > > >> > due > > > >> > > to > > > >> > > > > >>> Labour Day, and some teething issues were fixed > yesterday, > > > we > > > >> > will > > > >> > > > let > > > >> > > > > it > > > >> > > > > >>> run for a few more days so other committers and > > contributors > > > >> can > > > >> > > get > > > >> > > > a > > > >> > > > > >>> chance to try it out and share their experience after > the > > > >> > > > > >> experiment/trial > > > >> > > > > >>> is concluded. > > > >> > > > > >>> > > > >> > > > > >>> > > > >> > > > > >>> > > > >> > > > > >>> On Wed, 30 Apr 2025 at 13:59, Kaxil Naik < > > > kaxiln...@gmail.com > > > >> > > > > >> > > > wrote: > > > >> > > > > >>> > > > >> > > > > >>>> Whoops yeah. > > > >> > > > > >>>> > > > >> > > > > >>>>> Yep. Because it did not have all conversations > resolved. > > > We > > > >> > also > > > >> > > > have > > > >> > > > > >>>> "require resolved conversation" as one of the branch > > > >> protection > > > >> > > > > >>>> conditions. > > > >> > > > > >>>> I resolved the conversation and it got merged > > > automatically. > > > >> > > > > >>>> > > > >> > > > > >>>> Let's adapt it when ready though, I don't see any > urgency > > > of > > > >> > > getting > > > >> > > > > >>>> enabling auto-merge or getting it contributed > immediately > > > to > > > >> asf > > > >> > > > INFRA > > > >> > > > > >> when > > > >> > > > > >>>> it isn't critical. It is about priortization > > > >> > > > > >>>> > > > >> > > > > >>>> I'd say - if that is really bothering us - let's shape > > the > > > >> > feature > > > >> > > > > >> rather > > > >> > > > > >>>>> than outright reject it. > > > >> > > > > >>>> > > > >> > > > > >>>> On Wed, 30 Apr 2025 at 12:37, Jarek Potiuk < > > > ja...@potiuk.com > > > >> > > > > >> > > > wrote: > > > >> > > > > >>>> > > > >> > > > > >>>>> On Wed, Apr 30, 2025 at 7:55 AM Kaxil Naik < > > > >> > kaxiln...@gmail.com> > > > >> > > > > >> wrote: > > > >> > > > > >>>>>> To the point that the original PR is still not merged > > > even > > > >> > > after I > > > >> > > > > >> had > > > >> > > > > >>>>>> re-triggered the failed tests yesterday: > > > >> > > > > >>>>>> https://github.com/apache/airflow/pull/49727 > > > >> > > > > >>>>>> > > > >> > > > > >>>>>> > > > >> > > > > >>>>> Yep. Because it did not have all conversations > resolved. > > > We > > > >> > also > > > >> > > > have > > > >> > > > > >>>>> "require resolved conversation" as one of the branch > > > >> protection > > > >> > > > > >>>>> conditions. > > > >> > > > > >>>>> I resolved the conversation and it got merged > > > automatically. > > > >> > > > > >>>>> > > > >> > > > > >>>>> > > > >> > > > > >>>>>> On Wed, 30 Apr 2025 at 11:20, Kaxil Naik < > > > >> kaxiln...@gmail.com > > > >> > > > > > >> > > > > >> wrote: > > > >> > > > > >>>>>>> The gitbox escape hatch isn't it though -- if we are > > to > > > >> allow > > > >> > > > that > > > >> > > > > >>>>> why > > > >> > > > > >>>>>> not > > > >> > > > > >>>>>>> just allow people to merge it directly from github > > that > > > >> to go > > > >> > > via > > > >> > > > > >> an > > > >> > > > > >>>>>>> "escape hatch". > > > >> > > > > >>>>> Generally speaking GitHub has this option. Currently > > > >> "admins" > > > >> > > have > > > >> > > > a > > > >> > > > > >>>>> possibility of overriding branch protection (via UI). > > And > > > it > > > >> > > would > > > >> > > > be > > > >> > > > > >>>>> possible - if INFRA will allow it - to possibly add an > > > >> > .asf.yaml > > > >> > > > > >> feature > > > >> > > > > >>>>> to > > > >> > > > > >>>>> also allow branch protection override for all > committers > > > or > > > >> a > > > >> > > > subset > > > >> > > > > of > > > >> > > > > >>>>> the > > > >> > > > > >>>>> committers (PMC Members ? ). This is more of a > > limitation > > > of > > > >> > the > > > >> > > > > >> current > > > >> > > > > >>>>> implementation of permissions than a missing feature. > If > > > we > > > >> all > > > >> > > > feel > > > >> > > > > >> that > > > >> > > > > >>>>> the gitbox escape hatch is not enough, we can likely > > even > > > >> > > > contribute > > > >> > > > > >>>>> such a > > > >> > > > > >>>>> feature to .asf.yaml - if INFRA will be ok with the > > > option. > > > >> > It's > > > >> > > > very > > > >> > > > > >>>>> easy > > > >> > > > > >>>>> to contribute to - INFRA made it possible, we have a > new > > > >> > > framework: > > > >> > > > > >>>>> https://github.com/apache/infrastructure-asfyaml - we > > can > > > >> even > > > >> > > > > >> implement > > > >> > > > > >>>>> "airflow-only" .asf.yaml feature, that will not be > > > initially > > > >> > > > > available > > > >> > > > > >> to > > > >> > > > > >>>>> other ASF projects and later we can promote it to be > > > >> available > > > >> > to > > > >> > > > > >>>>> everyone. > > > >> > > > > >>>>> > > > >> > > > > >>>>> I'd say - if that is really bothering us - let's shape > > the > > > >> > > feature > > > >> > > > > >> rather > > > >> > > > > >>>>> than outright reject it. > > > >> > > > > >>>>> > > > >> > > > > >>>>> > > > >> > > > > >>>>>>> I am -1 on this auto-merge feature > > > >> > > > > >>>>>>> > > > >> > > > > >>>>> Understood :). But let's give it a bit more time as > well > > > and > > > >> > > maybe > > > >> > > > > >>>>> improve > > > >> > > > > >>>>> it (see above) - unless we really feel we are blocked > > now > > > - > > > >> > then > > > >> > > it > > > >> > > > > >>>>> should > > > >> > > > > >>>>> be as easy as merging an .asf.yaml change to disable > it. > > > >> > > > > >>>>> > > > >> > > > > >>>>> > > > >> > > > > >>>>>>> On Wed, 30 Apr 2025 at 11:18, Kaxil Naik < > > > >> > kaxiln...@gmail.com> > > > >> > > > > >>>>> wrote: > > > >> > > > > >>>>>>>> That’s not a single person, it impacts the > committers > > > and > > > >> > the > > > >> > > PR > > > >> > > > > >>>>> author > > > >> > > > > >>>>>>>> involved too. I don’t see how team productivity > soars > > > >> here. > > > >> > > > > >>>>>>>> > > > >> > > > > >>>>>>>> On Wed, 30 Apr 2025 at 02:39, Jarek Potiuk < > > > >> > ja...@potiuk.com> > > > >> > > > > >>>>> wrote: > > > >> > > > > >>>>>>>>> But yes, I also miss the previous "merge because I > > > think > > > >> > it's > > > >> > > > > >> safe" > > > >> > > > > >>>>>>>>> workflow. > > > >> > > > > >>>>>>>>> > > > >> > > > > >>>>>>>>> I badly miss it. Personally, It hurts my > > productivity. > > > >> > > > > >>>>>>>>> > > > >> > > > > >>>>>>>>> But I think the "require status check" to be green > > is > > > >> great > > > >> > > for > > > >> > > > > >>>>> "team > > > >> > > > > >>>>>>>>> productivity". Usually when single person is > > impacted > > > >> more > > > >> > > than > > > >> > > > > >>>>> team in > > > >> > > > > >>>>>>>>> general, it's worse for the person impacted, but > > team > > > >> > > > > >> productivity > > > >> > > > > >>>>>> soars. > > > >> > > > > >>>>>>>>> J. > > > >> > > > > >>>>>>>>> > > > >> > > > > >>>>>>>>> > > > >> > > > > >>>>>>>>> On Tue, Apr 29, 2025 at 11:03 PM Jarek Potiuk < > > > >> > > > ja...@potiuk.com> > > > >> > > > > >>>>>> wrote: > > > >> > > > > >>>>>>>>>> Just to add comment: > > > >> > > > > >>>>>>>>>> > > > >> > > > > >>>>>>>>>> a) there was some instability of "celery/boto" > > > hanging > > > >> > tests > > > >> > > > > >>>>> today > > > >> > > > > >>>>>>>>> that is > > > >> > > > > >>>>>>>>>> rather difficult to address - but we worked > around > > it > > > >> by > > > >> > > just > > > >> > > > > >>>>>> removing > > > >> > > > > >>>>>>>>>> "special-tests" from pre-requisite of merging > > > >> > > > > >>>>>>>>>> b) GitHub today (like literally today!) started > to > > be > > > >> > picky > > > >> > > on > > > >> > > > > >>>>> "too > > > >> > > > > >>>>>>>>> many > > > >> > > > > >>>>>>>>>> requests" - I addressed it today for both helm > > chart > > > >> and > > > >> > our > > > >> > > > > >>>>> release > > > >> > > > > >>>>>>>>> tests > > > >> > > > > >>>>>>>>>> (we are using bearer-token to authenticate and > > > increase > > > >> > the > > > >> > > > > >>>>> limit - > > > >> > > > > >>>>>>>>> and we > > > >> > > > > >>>>>>>>>> added cache on downloading json schema that was > > > >> downloaded > > > >> > > > > >>>>> "per-test" > > > >> > > > > >>>>>>>>>> c) in cases like the one mentioned above with > > > >> intermittent > > > >> > > > > >>>>> failures - > > > >> > > > > >>>>>>>>>> simple "rerun failed jobs" (assuming it will > > succeed > > > >> after > > > >> > > > > >>>>> rerun) - > > > >> > > > > >>>>>> is > > > >> > > > > >>>>>>>>>> essentially equivalent of "merge" (unless it > fails > > > >> again > > > >> > > which > > > >> > > > > >>>>> for me > > > >> > > > > >>>>>>>>> is a > > > >> > > > > >>>>>>>>>> signal of "DO NOT MERGE") > > > >> > > > > >>>>>>>>>> d) we always have the "gitbox" escape hatch - > that > > > >> allows > > > >> > > any > > > >> > > > > >>>>>>>>> committer to > > > >> > > > > >>>>>>>>>> push the fix directly, bypassing the limits: > > > >> > > > > >>>>>>>>>> > > > >> > > > > >>>>>>>>>> This is a simple thing for committers: > > > >> > > > > >>>>>>>>>> > > > >> > > > > >>>>>>>>>> git add remote gitbox > > > >> > > > > >>>>>> https://gitbox.apache.org/repos/asf/airflow.git > > > >> > > > > >>>>>>>>>> git fetch gitbox > > > >> > > > > >>>>>>>>>> git commit --amend ("add #PR number") > > > >> > > > > >>>>>>>>>> git push gitbox BRANCH_NAME:main (you need to > > provide > > > >> your > > > >> > > > > >>>>> apache id > > > >> > > > > >>>>>>>>> and > > > >> > > > > >>>>>>>>>> password) > > > >> > > > > >>>>>>>>>> > > > >> > > > > >>>>>>>>>> This is a nice escape hatch that we can use as > > > >> > "exceptional > > > >> > > > > >>>>>> workflow" - > > > >> > > > > >>>>>>>>>> and it works - I did it quite a few times over > the > > > last > > > >> > few > > > >> > > > > >>>>> days. Not > > > >> > > > > >>>>>>>>> UI > > > >> > > > > >>>>>>>>>> controlled, but IMHO exceptional workflow should > > be - > > > >> > well > > > >> > > - > > > >> > > > > >>>>>>>>> exceptional. > > > >> > > > > >>>>>>>>>> J. > > > >> > > > > >>>>>>>>>> > > > >> > > > > >>>>>>>>>> > > > >> > > > > >>>>>>>>>> On Tue, Apr 29, 2025 at 8:52 PM Kaxil Naik < > > > >> > > > > >> kaxiln...@gmail.com> > > > >> > > > > >>>>>>>>> wrote: > > > >> > > > > >>>>>>>>>>> Similar experience as Elad, I am in favor of > > > >> disabling it > > > >> > > > tbh. > > > >> > > > > >>>>> For > > > >> > > > > >>>>>>>>>>> example, > > > >> > > > > >>>>>>>>>>> https://github.com/apache/airflow/pull/49727 > has > > a > > > >> > failing > > > >> > > > > >>>>> test as > > > >> > > > > >>>>>>>>> below > > > >> > > > > >>>>>>>>>>> -- > > > >> > > > > >>>>>>>>>>> which is not an issue, and test passes locally > so > > I > > > >> would > > > >> > > > want > > > >> > > > > >>>>> to > > > >> > > > > >>>>>>>>> merge it > > > >> > > > > >>>>>>>>>>> but I can't. > > > >> > > > > >>>>>>>>>>> > > > >> > > > > >>>>>>>>>>> FAILED > > > >> > > > > >>>>>>>>>>> > > > >> > > > > >>>>>>>>>>> > > > >> > > > > >> > > > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > >> > > > > > > helm-tests/tests/helm_tests/airflow_aux/test_basic_helm_chart.py::TestBaseChartTest::test_priority_classes > > > >> > > > > >>>>>>>>>>> - requests.exceptions.HTTPError: 429 Client > Error: > > > Too > > > >> > Many > > > >> > > > > >>>>> Requests > > > >> > > > > >>>>>>>>> for > > > >> > > > > >>>>>>>>>>> url: > > > >> > > > > >>>>>>>>>>> > > > >> > > > > >>>>>>>>>>> > > > >> > > > > >> > > > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > >> > > > > > > https://raw.githubusercontent.com/yannh/kubernetes-json-schema/master/v1.29.1-standalone-strict/priorityclass-scheduling-v1.json > > > >> > > > > >>>>>>>>>>> On Tue, 29 Apr 2025 at 18:29, Jarek Potiuk < > > > >> > > ja...@potiuk.com > > > >> > > > > > > > >> > > > > >>>>>> wrote: > > > >> > > > > >>>>>>>>>>>> On Tue, Apr 29, 2025 at 1:46 PM Elad Kalif < > > > >> > > > > >>>>> elad...@apache.org> > > > >> > > > > >>>>>>>>> wrote: > > > >> > > > > >>>>>>>>>>>>> Thanks for that Jarek! > > > >> > > > > >>>>>>>>>>>>> I find the lack of ability to merge PRs fast > > very > > > >> > > limiting > > > >> > > > > >>>>> but > > > >> > > > > >>>>>> it > > > >> > > > > >>>>>>>>>>> might > > > >> > > > > >>>>>>>>>>>> be > > > >> > > > > >>>>>>>>>>>>> just something to get used to. > > > >> > > > > >>>>>>>>>>>>> > > > >> > > > > >>>>>>>>>>>> Indeed. I also see it, but also I got a few > > > manually > > > >> > > pushed > > > >> > > > > >>>>> "must > > > >> > > > > >>>>>>>>> fix > > > >> > > > > >>>>>>>>>>>> quickly" to gitbox, and actually I find it > really > > > >> nice - > > > >> > > > > >>>>> because > > > >> > > > > >>>>>> it > > > >> > > > > >>>>>>>>> is > > > >> > > > > >>>>>>>>>>>> still possible, but it require some extra > effort > > > and > > > >> > > > > >>>>> deliberate > > > >> > > > > >>>>>> "ok > > > >> > > > > >>>>>>>>> that > > > >> > > > > >>>>>>>>>>>> one really should be pushed to unblock > everyone" > > - > > > as > > > >> > long > > > >> > > > > >> as > > > >> > > > > >>>>> we > > > >> > > > > >>>>>> all > > > >> > > > > >>>>>>>>>>>> (especially those people that are active in the > > > >> > > > > >>>>>>>>>>>> #internal-airfow-ci-cd channel) know how to do > it > > > and > > > >> > can > > > >> > > > > >> fix > > > >> > > > > >>>>>> things > > > >> > > > > >>>>>>>>>>>> quickly, this is actually a nice way to make it > > > into > > > >> > > > > >>>>> "exceptional" > > > >> > > > > >>>>>>>>>>> workflow > > > >> > > > > >>>>>>>>>>>> - which will push us more in making sure > airflow > > > >> main is > > > >> > > > > >>>>> really > > > >> > > > > >>>>>>>>> "green" > > > >> > > > > >>>>>>>>>>> - > > > >> > > > > >>>>>>>>>>>> which ultimately is our goal to make it as > green > > as > > > >> > > possible > > > >> > > > > >>>>> all > > > >> > > > > >>>>>> the > > > >> > > > > >>>>>>>>>>> time. > > > >> > > > > >>>>>>>>>>>> What **might help with that** (and also keeping > > the > > > >> > > "enable > > > >> > > > > >>>>> auto > > > >> > > > > >>>>>>>>> merge" > > > >> > > > > >>>>>>>>>>>> might motivate it more to) is to: > > > >> > > > > >>>>>>>>>>>> > > > >> > > > > >>>>>>>>>>>> * speed up the builds - we MUST prioritise now > > ARC > > > >> (K8S > > > >> > > > > >>>>>> self-hosted > > > >> > > > > >>>>>>>>>>>> runners) to make our builds simply faster - I > > > >> started a > > > >> > > > > >>>>> discussion > > > >> > > > > >>>>>>>>> and a > > > >> > > > > >>>>>>>>>>>> small group of people who can work together to > > > >> complete > > > >> > it > > > >> > > > > >>>>> after > > > >> > > > > >>>>>>>>>>> Hussein's > > > >> > > > > >>>>>>>>>>>> POC) > > > >> > > > > >>>>>>>>>>>> * speed up the image release - with ARM runners > > > >> (which > > > >> > we > > > >> > > > > >>>>> might be > > > >> > > > > >>>>>>>>> able > > > >> > > > > >>>>>>>>>>> to > > > >> > > > > >>>>>>>>>>>> do independently as recently I think we have > > > >> > > > > >>>>> hypervisor-enabled > > > >> > > > > >>>>>> ARM > > > >> > > > > >>>>>>>>>>> images > > > >> > > > > >>>>>>>>>>>> available as public runners as github made it > > > >> generally > > > >> > > > > >>>>>> available). > > > >> > > > > >>>>>>>>>>>> * speed up the doc builds for airflow-site - we > > > >> (mainly > > > >> > > > > >>>>> Pavan) are > > > >> > > > > >>>>>>>>>>> close to > > > >> > > > > >>>>>>>>>>>> complete offloading of the historical release > > docs > > > >> to S3 > > > >> > > > > >> and I > > > >> > > > > >>>>>> hope > > > >> > > > > >>>>>>>>> it > > > >> > > > > >>>>>>>>>>> will > > > >> > > > > >>>>>>>>>>>> cut down a lot on doc publishing workflows. > > > >> > > > > >>>>>>>>>>>> > > > >> > > > > >>>>>>>>>>>> J, > > > >> > > > > >>>>>>>>>>>> > > > >> > > > > > > > >> > > > > > > > >> > --------------------------------------------------------------------- > > > >> > > > > To unsubscribe, e-mail: dev-unsubscr...@airflow.apache.org > > > >> > > > > For additional commands, e-mail: > dev-h...@airflow.apache.org > > > >> > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > >> > > > > > > > > > >
