Sorry, I dont get your message. For cloudberry main, I proposed to include only CVE fixes (p2 in my proposal). It is about 20 commits. I dont get why this is bad.
On Mon, 9 Feb 2026 at 14:27, Jinbao Chen <[email protected]> wrote: > > If we've already decided to upgrade from pg14 to pg16, what's the point of > introducing code from pg14.4 to pg14.20 onto the master branch? The future > Cloudberry 3x will be released based on pg16, so the code from pg14.4 to > pg14.20 can only be applied to the Cloudberry 2x. In that case, why not put > this code on the REL_2_STABLE branch? > > On Mon, Feb 9, 2026 at 5:07 PM Kirill Reshke <[email protected]> wrote: > > > On Mon, 9 Feb 2026 at 13:37, Jinbao Chen <[email protected]> wrote: > > > > > > I believe the introduction of Postgres stable branch code should occur on > > > Cloudberry's stable branches, > > > such as REL_2_STABLE. > > > > > > In theory, our main branch should only upgrade the code of the PostgreSQL > > > master branch. > > > > yes, agreed, cloudberry main == cloudberry over pg19 would be great. > > > > > Only after we switch to a > > > stable branch such as 'REL_2_STABLE' should we upgrade the code of the > > > PostgreSQL stable branch. > > > Introducing a large amount of code from the Postgres stable branch into > > > cloudberry/main will cause significant > > > problems for main version upgrades. The introduction of non-linear codes > > > can cause intractable conflicts. > > > > > > I suggest this upgrade should be performed on REL_2_STABLE. > > > > I see your rationale on this, and agree with it. But things are > > already very complicated for the main branch... > > I think we should cherry-pick all CVE fixes here for sure, and given > > that main is over PG14, this would be a cherry-pick from > > REL_14_STABLE. > > However, I can see that if this rebase process is fully completed > > against main (adding ~1300 commits to it), it would be extremely > > troublesome to complete 14-16 kernel upgrade. > > > > So, my (updated) proposal: > > > > 1) Do kernel (14.4 - 14.20) rebase over REL_2_STABLE > > 2) Have all CVE fixes from 14.4 - 14.20 into main (almost done, actually) > > 3) Do 16.9 - 16.12 upgrade in cbdb-postgres-merge/ branch (I can also > > help with that) > > > > 3*) In some distant future, the main branch of cloudberry will always > > be in sync with Postrges master... > > > > Does it sound? > > > > > > > > On Fri, Feb 6, 2026 at 6:20 PM Dianjin Wang <[email protected]> > > wrote: > > > > > > > Cool! I created a GitHub Project: > > > > https://github.com/orgs/apache/projects/572/views/1, feel free to > > > > edit. > > > > > > > > Also agreed with your schema. Thanks! > > > > > > > > Best, > > > > Dianjin Wang > > > > > > > > On Fri, Feb 6, 2026 at 4:34 PM Kirill Reshke <[email protected]> > > > > wrote: > > > > > > > > > > Here [0] is an old-style excel with all commits between 14.4 and > > > > > 14.20, just a list without any sort of analysis for now. > > > > > > > > > > I guess we can create github project for this upgrade process, and > > > > > have here tickets for each incremental step (14.4 - 14.5, 14.5 - > > 14.6) > > > > > > > > > > So, we will use both [0] and github projects. > > > > > > > > > > Also, regarding the 2.x/3.x policy. I propose a scheme where > > > > > cherry-pick PR (which in turn can be a number of closely-related > > > > > commits) is always created for the main branch, reviewed and merged > > > > > here, and then Cloudberry committer, responsible for the PR simply > > > > > pushes changes to REL_2_x without addiniginal PR/review. Does it > > > > > sound? I think 14.4 - 14.20 commits are good in terms of code > > quality > > > > > and ABI stability, so this might work. > > > > > > > > > > > > > > > Thoughts? > > > > > > > > > > [0] > > > > > > https://docs.google.com/spreadsheets/d/1vjjEb39QPyXO-nDJZ0tHAtReIQKka0S2YnD2r1AFhkk/edit?gid=0#gid=0 > > > > > > > > > > On Fri, 6 Feb 2026 at 12:22, Kirill Reshke <[email protected]> > > > > wrote: > > > > > > > > > > > > On Fri, 6 Feb 2026 at 09:13, Dianjin Wang <[email protected]> > > > > wrote: > > > > > > > > > > > > > > Hi Kirill, > > > > > > > > > > > > > > On Thu, Feb 5, 2026 at 11:08 PM Kirill Reshke < > > > > [email protected]> wrote: > > > > > > > > > > > > > > > > Sure > > > > > > > > This will in fact resolve many problems, not only CVE > > > > > > > > So, how do we organize this? Do we need big excel as in gpdb > > > > > > > > cherry-pick process? > > > > > > > > > > > > > > > > > > > > > > I think both approaches could work well — a shared Google Sheet > > or a > > > > > > > GitHub Project/issue tracker. The key is to keep the progress > > > > > > > transparent and make it easy for others to participate and > > > > contribute. > > > > > > > > > > > > > > I want to share more ideas on the minior kernel upgrade for the > > > > reference. > > > > > > > > > > > > > > Between PG 14.4 and 14.20 there are ~1352 commits, so a phased > > > > upgrade > > > > > > > could be a reasonable approach. For example, upgrading > > incrementally > > > > > > > (14.4 → 14.5 → 14.6, etc. ~100 commits per step) or grouping > > several > > > > > > > minor versions per step could help keep the process more > > controlled > > > > > > > and reduce risk. Curious to hear what others think. > > > > > > > > > > > > I don't have a strong opinion here. But to keep the Cloudberry > > project > > > > > > more Postgres-y, let's try an incremental approach . > > > > > > > > > > > > > BTW, would you be interested in leading this upgrade effort, if > > you > > > > > > > have the bandwidth? Having a coordinator would greatly help drive > > > > this > > > > > > > forward. > > > > > > > > > > > > I would love to! But I'm a little inexperienced in the GitHub > > > > > > Project/issue tracker. Anyway I can cherry-pick for sure and manage > > > > > > commit statuses/reviewing other people's PRs. > > > > > > > > > > > > > Best, > > > > > > > Dianjin Wang > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > To unsubscribe, e-mail: [email protected] > > > > > > > For additional commands, e-mail: [email protected] > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Best regards, > > > > > > Kirill Reshke > > > > > > > > > > > > > > > > > > > > -- > > > > > 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] > > > > > > > > > > > > > > > > -- > > Best regards, > > Kirill Reshke > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > -- Best regards, Kirill Reshke --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
