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