potiuk commented on PR #30727: URL: https://github.com/apache/airflow/pull/30727#issuecomment-1535974200
> I don't personally see this PR as being exceptionally dangerous or difficult to review beyond a standard PR that shuffles a few classes around. I think we've all seen and reviewed plenty of PRs that are WAY larger. Yeah. We did. But we often very carefully debated when to merge the change in the past and the question of cherry-pickability has been an important decision making factor. Usually when we did big refactors like that we parked such changes to before the cut-off in the past. This is nothing new (usually it happened when we had bigger refactors across the whole codebase though). This one is a bit different as it is localized. > In my opinion, we should proceed and merge this PR to main. If it results in issues while cherry-picking changes, we can ask the involved contributors for help in navigating those. Does it add more responsibility to the Release managers? Yes, it does. Nonetheless, I believe it is the lesser of the two evils because we should expect only a few changes to be cherry-picked in patch releases. Conversely, in the other scenario, the contributor will need to keep an eye on ALL the changes. Not really. I disagree. It only takes to PARK this change and redo it once before the cuttof. It does not have to be continuosly rebased. With any change like that there are two things that can be carried over: 1) the actually changed code 2) the IDEA what should be changed I like the idea behind the change. It's cool. But if the changed code is merged now, it will either carry the risk in the bugfix branch or make it more difficult for release managers. The only "evil" we are weighting here is whether to implement the idea now or later. There is no more "evil" happening than choosing implementing the idea later (And yes, sinking some work already done by @o-nikolas) . However I'd argue (and I've done that multiple times in the past) that redoing such a change some time later that you already have proven that it can be done and looking at your past changes, is multiple times faster (and less error prone) than doing it for the first time. I even sometimes deliberately drop the change like that I've done to do it again starting from newer codebase, and it is usually cleaner and super-fast to do. So my proposal is not to carry the code and look at all the other changes, but to carry the idea of the change and implement it when the time is ripe. I even offer to do it together with @o-nikolas - when we will be extracting the k8S executor to provider - as @eladkal suggested, then we can both together iterate on the change and it will even have the nice angle of pair-programming aspect which we could do together. Maybe that is the best way? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
