@Jens: yup precisely, I do expect changes to only v2 branch. This is also what we did during v2 release and worked well for us.
On Sun, 28 Jul 2024 at 11:59, Ephraim Anierobi <ephraimanier...@gmail.com> wrote: > From how the cherrypicker works, it looks like something we need. We could > have a bot that adds a "review comment" that must be resolved before > merging. The review comment can ask for a label to be added to the PR if > the PR should be backported to Airflow 2. Whoever is merging the PR can > determine if it should be backported or not and add the appropriate label. > > > On Fri, 26 Jul 2024 at 20:14, Jarek Potiuk <ja...@potiuk.com> wrote: > > > Same comment as Jens. There will be things removed in Airflow-3 that will > > need only-Airflow-2 fixes. > > > > I like the idea of automated cherry-picker, but it only make sense if we > > pay attention to which PRs are going to be cherry-picked and do so at the > > moment of merging - we are going to have many changes that will not be > > supposed to be cherry-picked, so we need to have "opt-in" approach where > we > > explicitly say "this PR should be cherry-picked to v2". > > > > I think it's absolutely worth doing it- cherry-picking in sequential > order > > as things are merged makes a lot of sense - but it needs some > deliberation > > and decision making at the moment of merging (should this one be > > cherry-picked?) - and assigning responsibility to who should be making > that > > decision. But 100% I think it makes sense to do it at "merge" time rather > > than release time, because rather than having to make 100 decisions by a > > single person at release time, 100 people might make separate decisions > > (and follow-up when cherry-pick fails) for a long time. > > > > So technically it's fine, but it needs a well defined process and (say) > > everyone who is merging PRs to pay attention to it. It's more of a social > > than technical problem. Not sure if we will be able to make it work with > > our distributed setup. > > > > My 3 cents. > > > > J. > > > > > > On Fri, Jul 26, 2024 at 8:45 PM Scheffler Jens (XC-AS/EAE-ADA-T) > > <jens.scheff...@de.bosch.com.invalid> wrote: > > > > > I fully agree. We should document it. > > > > > > There is one exceptional case. In my view this should be planned and > > > documented as exception: if something needs to be fixed that is not on > > main > > > anymore (e.g. code to integrate Fab) then a fix pr mist be made against > > > v2-10-test branch as it can not be made against main - also assuming > that > > > such big is not relevant for 3.x line. > > > > > > Jens > > > > > > Sent from Outlook for iOS<https://aka.ms/o0ukef> > > > ________________________________ > > > From: Kaxil Naik <kaxiln...@gmail.com> > > > Sent: Friday, July 26, 2024 7:41 PM > > > To: dev@airflow.apache.org <dev@airflow.apache.org> > > > Subject: Re: [DISCUSS] Approaches to bugfixes for 2.10 after main > becomes > > > 3.0 > > > > > > Nice, that is indeed promising > > > > > > On Fri, 26 Jul 2024 at 18:30, Tzu-ping Chung <t...@astronomer.io.invalid > > > > > wrote: > > > > > > > It was also mentioned in the call chat, CPython uses cherry-picker[1] > > to > > > > automatically create cherry-pick PRs for version branches. They have > a > > > > GitHub bot that listens to PR events, and when a PR is merged to > main, > > > > automatically creates back-porting PRs. You can see it in action > > here[2] > > > > (just a random PR). > > > > > > > > They use labels to determine what versions to back port to, but the > > case > > > > is a lot simpler for Airflow—I think we simply needs to apply one > label > > > to > > > > mark a PR should be back ported. > > > > > > > > If the tool encounters any problems during cherry-picking (generally > > > > conflicts), the bot would also comment in the original PR to ask for > a > > > back > > > > port to be manually created[3]. They have additional bots to ensure > > this > > > is > > > > enforced, but again Airflow probably does not need this much > > > infrastructure. > > > > > > > > > > > > [1]: > > > > > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpypi.org%2Fproject%2Fcherry_picker%2F&data=05%7C02%7CJens.Scheffler%40de.bosch.com%7C431ec61f820943c851e708dcad9a2968%7C0ae51e1907c84e4bbb6d648ee58410f4%7C0%7C0%7C638576124826168130%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=xJ%2FAnqyHFyc6OHSr3t1ZAGmK%2FQjHJGLAm1nMa0nDXJI%3D&reserved=0 > > > <https://pypi.org/project/cherry_picker/> > > > > [2]: > > > > > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fpython%2Fcpython%2Fpull%2F122312&data=05%7C02%7CJens.Scheffler%40de.bosch.com%7C431ec61f820943c851e708dcad9a2968%7C0ae51e1907c84e4bbb6d648ee58410f4%7C0%7C0%7C638576124826178921%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=4nKUiqqO0bc7BIiCTJ3UdjJA3bi5f7u%2B2Ry5d2BtRyo%3D&reserved=0 > > > <https://github.com/python/cpython/pull/122312> > > > > [3]: > > > > > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fpython%2Fcpython%2Fpull%2F27625%23issuecomment-894672175&data=05%7C02%7CJens.Scheffler%40de.bosch.com%7C431ec61f820943c851e708dcad9a2968%7C0ae51e1907c84e4bbb6d648ee58410f4%7C0%7C0%7C638576124826185912%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=Gf7Ey2quisKsdrlLRfkagjam0fTzM60WQP2cU8fPv4E%3D&reserved=0 > > > <https://github.com/python/cpython/pull/27625#issuecomment-894672175> > > > > > > > > > > > > > On 27 Jul 2024, at 01:07, Kaxil Naik <kaxiln...@gmail.com> wrote: > > > > > > > > > > Hi all, > > > > > > > > > > In the last Airflow 3 dev call yesterday, we agreed that the main > > > branch > > > > will become the Airflow 3.0 branch on 9th August after 2.10.0rc1 is > > cut. > > > > Once that happens, we need to handle bugfixes PR differently, as we > > want > > > to > > > > continue releasing bugfixes as part of 2.10 patch releases. The > > codebase > > > in > > > > the main branch will contain breaking changes and might have diverged > > > > significantly from the 2.10 branch. This means the cherry-picking > > process > > > > isn't straightforward for PRs touching code is different for 2.10 vs > > 3.0. > > > > > > > > > > There was a consensus that the general policy should be: "All bug > > fixes > > > > will target Airflow 3. We will make the best effort to make them > > > available > > > > in 2.10.x, but if somebody wants to guarantee that a fix is included > in > > > > 2.10.x, they need to raise the PR explicitly to the v2-10-test > branch." > > > > > > > > > > My proposal is simple but manual: When merging bugfix PRs to the > main > > > > branch, the committers should also try to cherry-pick it to > v2-10-test > > > > branch. If there are merge conflicts, the committer should add a > > comment > > > on > > > > the original PR, informing the author and asking them to raise a > > separate > > > > PR against v2-10-test branch. If this doesn't happen, there is no > > > guarantee > > > > that the PR will be part of 2.10. > > > > > > > > > > TP mentioned that he knew of workflows used by some existing > projects > > > > that we can compare and consider as an option. Could you expand on > > that, > > > > @Tzu-ping Chung <mailto:t...@astronomer.io> ? > > > > > > > > > > If anyone has other ideas or thoughts, let's discuss them here. > > > > > > > > > > Regards, > > > > > Kaxil > > > > > > > > > > > > > > > > > > >
