When a new PR is merged into the main branch, the feature branch should, in theory, rebase onto the main branch. However, because this specific merge PR is massive—containing all the code for Postgres 15 and 16 along with numerous bug fixes—a rebase has become practically impossible. Consequently, the merge PR must instead merge the main branch into itself, which will create an additional merge commit on top of the Postgres 16 merge. Eliminating this redundant merge commit requires highly complex Git operations, which takes time and introduces risk.
Other PRs do not suffer from this issue. They can follow the standard workflow and rebase normally, which is much simpler and less risky than handling the merge PR. At the same time, if we choose to wait two to three weeks for existing PRs to merge, new PRs will inevitably keep coming in anyway. What, then, would be the point of waiting? On Mon, May 25, 2026 at 4:18 PM Dianjin Wang <[email protected]> wrote: > Hi Jinbao, all, > > First of all, I completely understand the concern about keeping the main > branch blocked for too long, especially considering the size of this work > and the complexity of continuously rebasing such a large upgrade branch. (I > believe some PRs an be merged by now, but still not somehow). > > However, I think this transition is not only about merging the PostgreSQL > 16 kernel into the main repository itself, but also about preparing the > broader Cloudberry ecosystem for the transition from PG14 to PG16. > > For example, several ecosystem components and CI pipelines are currently > still tightly coupled with the existing main branch, including: PXF, > cloudberry-backup and potentially other downstream components. > > Some time may be needed for contributors to evaluate how we can support > both PG14 and PG16 during the transition period. > > Also, the past three days included the weekend, and according to normal > Apache community practice, review windows around weekends are usually > considered differently since many contributors may be offline or on > vacation. > > Another concern is that we are also about to begin discussions around the > 2.2 release (Leonid will send a discussion email later maybe), while at the > same time there are still many active PRs currently under review on top of > the PG14-based main branch — especially around Orca, PAX, Planner, and > related areas. My concern is that once the main branch fully switches to > the PG16 kernel, many of these existing PRs may will not be simply > cherry-picked from the main to the 2.x release. I think it indeed needs a > good balance to handle with this situation. Everyone handles the rebased > work for PG16, or we do the rebase only once in the PG16 PR. > > Yesterday I had a brief private discussion with Max, my opinions (no > decision, just sharing): > > > - > > allowing a transition/review window (for example around 2–3 weeks), > - > > accelerating review and merge of the currently active PG14-based PRs > during this period, > - > > and then temporarily locking the main branch and performing a final > rebase/synchronization of the PG16 branch once - You don’t need to > repeatly > rebase to catch up the main’s changes > > I think this could help: > > > - > > reduce repeated rebase work for the PG16 PR, > - > > give ecosystem components some reaction/adaptation time, help us > coordinate with our next 2.x minor release, > - > > and help existing contributors land their in-flight work before the > kernel transition fully happens. > > A good strategy will help us. Just sharing these thoughts for discussion. > We can continue the discussion here, or an open meeting on this. Thanks > again for driving this huge effort forward. > > Best, > Dianjin Wang > > Jinbao Chen <[email protected]>于2026年5月26日 周二01:27写道： > > > Hi all, > > It has been three days since the PR was submitted. I intend to merge it > > into the main branch today. > > Why I chose not to wait any longer: > > Firstly, we cannot allow the main trunk to be blocked for an extended > > period. > > Secondly, the sheer size of this PR makes a thorough and effective review > > impossible. > > > > After merging, we will start fixing the FIXMEs. I am currently sorting > them > > out and converting them > > into features in project https://github.com/orgs/apache/projects/497 > > > > On Mon, May 25, 2026 at 3:08 AM Kirill Reshke <[email protected]> > > wrote: > > > > > On Mon, 25 May 2026 at 08:44, Zhang Mingli <[email protected]> > wrote: > > > >I think we should go ahead and merge it in. > > > > > > +1 > > > > > > > > > -- > > > Best regards, > > > Kirill Reshke > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [email protected] > > > For additional commands, e-mail: [email protected] > > > > > > > > >
