Hi all, One additional thought regarding the longer-term maintenance strategy after the PG16 merge stabilization work.
Since the current upgrade work brings Apache Cloudberry to PostgreSQL 16.9, I wonder whether, after the FIXME items and stabilization work are largely completed, we should consider continuing to roll forward within the PostgreSQL 16.x series (for example toward newer upstream minor releases such as 16.14 or later), before eventually starting a future PG18 upgrade cycle. Over the past year, while the PG14 → PG16 merge work was ongoing, PostgreSQL upstream has continued releasing additional 16.x minor updates containing bug fixes, stability improvements, and security-related fixes. I think continuing to track newer PostgreSQL 16.x minor releases incrementally may provide several benefits: * Reduce long-term divergence from PostgreSQL upstream. * Avoid accumulating another large maintenance gap. * Make future major-version upgrades easier and more incremental. * Help establish a more continuous upstream synchronization model for Cloudberry, rather than large periodic jumps. I think a rolling-update style upstream synchronization approach may help the project evolve more incrementally over time. Of course, I think stabilization and FIXME resolution should remain the first priority after the current merge lands. But once things become more stable, this may be a worthwhile direction for the community to consider. Just sharing this as a future maintenance thought for discussion. Best, Dianjin Wang On Tue, May 26, 2026 at 10:16 PM Kirill Reshke <[email protected]> wrote: > > Okay, so if I'm reading this correctly it's fine if I merge > https://github.com/apache/cloudberry/pull/1736 today, so we will be having > all viral fixes is current main. > I can also take an effort of merging this into to-be-main (pg16 merge) > branch, as well as other 16.10-16.14 CVE fixes. > Note that I'm speaking only about security fixes, which is about 50 > commits, not whole 16.10-16.14 range > > On Tue, 26 May 2026, 08:44 Dianjin Wang, <[email protected]> wrote: > > > 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] > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
