BTW. I'd be happy to capture result of this discussion if we can get to a consensus or vote eventually in the "cherry-picking" guidelines.
On Mon, Jun 23, 2025 at 12:42 PM Jarek Potiuk <ja...@potiuk.com> wrote: > I wanted to start a discussion on "things that we cherry-pick" (to vX_Z > branch). > > I think there are different opinions on what kind of changes should be > cherry-picked and it might be a good idea to agree on a common approach. > > I think (following the comment of Ash here) > https://github.com/apache/airflow/pull/51992#issuecomment-2995632849 that > we can use a very simplistic and (I'd say) dogmatic approach "only > cherry-pick bug fixes. Full stop". But I believe (and past experience from > a lot of cherry-picking that I've been doing - multiple times helping to > bring past branches to be green and spending countless hours on it, that it > should be a bit more nuanced. > > I would love to see what others think, but from my experience those are > the things that we **should** cherry-pick: > > > 1) bug-fixes (of course) > 2) doc changes (when they are improvements or filling gaps) > 3) dev tool changes (every time we did not, it resulted in hours of my > time when things were breaking and I tried to reconcile it) > 4) results of automated refactorings that have very low risks (in the > areas that are likely to have cherry-picks) > > t) - is non-controversial I think > > 2) - is also relatively non-controversial and very low risk and gives our > users a chance to get better docs earlier (even today for example I cherry > picked this one: https://github.com/apache/airflow/pull/52068 - because > one of my friends who tries to learn Airflow 3 pinged me that > "ConfiuguringRuff" link that we have in 3.0.2 leads to 404 NOT found > > 3) - it had always bitten us if we stopped cherry-picking dev tool > changes. The thing is that external dependencies change all the time and we > are continuously catching up with those, also we improve, speed up and > simplify the tooling - and often things that worked when branch was cut, > does not work today - countless, countless hours lost in one or two > branches when we stopped doing it - I think even once or twice I had to > just copy over most (but not all) the code from main to the branch and > commit one single "catch-up dev tooling with main" big change > > 4) Is likely most controversial - example here: > https://github.com/apache/airflow/pull/51992/ - those are the kind of > (really small) changes that are done in "active" area (i.e. area that had > and will have a lot of cherry-picks anyway, but they are done with > automated refactoring - like renaming variables and such. This introduces > clarity and readability, so this is good we are doing them. But if we do > not cherry-pick them and then we cherry-pick any change that touches the > same code, this lead to a conflict. Conflicts are frustrating, especially > those kinds - you never know what you should do - should you "merge" this > naming change with your change? or should you leave the original namiing, > or should you try to find the past commit that changed it and cherry-pick > it as well? This paired with the fact that we are using cherry-picker that > allows to cherry-pick stuff very quickly, automatically and painlessly when > there are no conflicts, make me think that yes - we should cherry -pick > those changes proactively as a service to those contributors who will > follow up with their cherry-picking. It's just "good service" and helping > others who will come after you. > > That's how my definition of "what we should cherry-pick" is... > > I wonder what others think about it ? > > J. > > > > > >
