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