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