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