Hi all, Thanks everyone for the discussion.
At this point, it seems the general consensus is leaning toward moving forward with merging the PG16 upgrade into the main branch soon. I respect and support the community consensus process here - disagree and commit, so let’s move forward together. That said, before the final merge operation happens, I still think it would be beneficial to leave a little more time (perhaps 1~2 more days) so contributors from other time zones also have a fair opportunity to participate in the discussion and review process. Also, in the parallel 2.2 release discussion thread started by Leonid, there was a suggestion to land key 2.2 features into the 2.x branch first. I personally support this direction. I think it addresses many of the concerns I mentioned earlier around transition coordination and ongoing in-flight work. With the 2.2 release work continuing for more time, I now agree that moving the PG16 kernel upgrade into the main branch sooner probably makes more sense overall. Before the merge happens, I think there are still several preparation steps that would help make the transition smoother (I’m happy to help with these tasks): * Create a copy branch from the current main branch (for example `PG14_ARCHIVE`) to mirror the existing PG14-based code line. * Apply a similar strategy to related ecosystem repositories where appropriate, including PXF and cloudberry-backup. * Clearly document the transition strategy for contributors, including which branches should receive PG14 fixes versus PG16-targeted development (can do after the PG16 merging). I think these steps can help reduce disruption during the transition period while still allowing us to move the PG16 work forward. Thanks again to everyone driving this huge effort. Best, Dianjin Wang On Tue, May 26, 2026 at 11:05 AM Jinbao Chen <[email protected]> wrote: > > 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] > > > > > > > > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
