Late to the discussion here but I agree that we should document the process (if we haven't already).
I also think that the automatic cherry picker is worth exploring. I also came across one of the github action plugins for backporting and it looks pretty good: https://github.com/marketplace/actions/backport-action. This action allows us to do the same stuff as TP suggested, along with label-wise filtering. Thanks & Regards, Amogh Desai On Sun, Jul 28, 2024 at 6:18 PM Kaxil Naik <kaxiln...@gmail.com> wrote: > This is also what we did during Airflow 2 release and worked well for us > where some changes were in Airflow 1 branch only since it had Flask Admin > vs FAB, and their were no concept of Provider in v1, Python 2 support etc > > > On Sun, 28 Jul 2024 at 13:45, Kaxil Naik <kaxiln...@gmail.com> wrote: > > > @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 > >> > > > > > >> > > > > >> > > > > >> > > > >> > > >> > > >
