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