Re: [DISCUSS] Enabling previously disabled test suites with increased container shared memory

[Max Yang]

👍

On Thu, Nov 21, 2024 at 4:01 PM Ed Espino  wrote:

> A fully green run! Total duration: 49m 46s
>
> https://github.com/edespino/cloudberry/actions/runs/11948311269
>
> Thank you 杨江华!
>
> -=e
>
> On Wed, Nov 20, 2024 at 11:27 PM 杨江华  wrote:
>
> > Hi , Ed
> > This setting just make explain test happy.
> > You can try it.
> >
> >
> > Ed Espino  于2024年11月21日周四 15:22写道：
> >
> > > Thank you for sharing this. I am familiar with the previous Cloudberry
> > > workflow file and the use of it for "icw-orca-test".
> > >
> > > Again, I thought the default optimizer setting is "on". In this case,
> is
> > > there a need to even set it?
> > >
> > > Notice after creating the demo cluster, the optimizer is set to "on".
> > >
> > >
> >
> https://github.com/edespino/cloudberry/actions/runs/11944371481/job/33295504090#step:14:247
> > >
> > > -=e
> > >
> > > On Wed, Nov 20, 2024 at 11:15 PM 杨江华  wrote:
> > >
> > > > Hi, Ed
> > > > refer to cloudberry :
> > > >
> > >
> >
> https://github.com/apache/cloudberry/blob/1.5.4/.github/workflows/build.yml
> > > > ```c++
> > > > icw-orca-test:
> > > > needs: build
> > > > runs-on: [self-hosted, example]
> > > > env:
> > > >   MAKE_TEST_COMMAND: "-k PGOPTIONS='-c optimizer=on'
> > > > installcheck-world"
> > > >   TEST_OS: "centos"
> > > >   DUMP_DB: "true"
> > > > ```
> > > > Here explicitly set PGOPTIONS='-c optimizer=on'.
> > > >
> > > >
> > > > Ed Espino  于2024年11月21日周四 15:00写道：
> > > >
> > > > > Please: you can call me Ed (艾德)
> > > > >
> > > > > I thought Orca (optimizer) was enabled by default. Is that not the
> > case
> > > > > with Cloudberry?
> > > > >
> > > > > -=e
> > > > >
> > > > >
> > > > >
> > > > > On Wed, Nov 20, 2024 at 10:51 PM 杨江华  wrote:
> > > > >
> > > > > > Dear Espino,
> > > > > >
> > > > > > I found that ic-good-opt-on pipeline failed to explain. You can
> set
> > > > > > PGOPTIONS='-c
> > > > > > optimizer=on' explicitly. Hope to solve this.
> > > > > >
> > > > > > Thank you for your time and support.
> > > > > >
> > > > > >
> > > > > > Ed Espino  于2024年11月21日周四 12:40写道：
> > > > > >
> > > > > > > I've identified a solution for running our previously disabled
> > test
> > > > > > suites
> > > > > > > (
> > > > > > > cbdb_parallel and instr_in_shmem_verify) in the GitHub Actions
> CI
> > > > > > > environment. By increasing the container shared memory using
> the
> > > > > > > --shm-size=2gb parameter, these test suites are now passing
> > > > > consistently.
> > > > > > >
> > > > > > > I'm currently conducting additional testing to verify the
> > stability
> > > > of
> > > > > > this
> > > > > > > solution. You can review the test results here:
> > > > > > >
> > > > > > >-
> > > https://github.com/edespino/cloudberry/actions/runs/11944371481
> > > > > > >-
> > > https://github.com/edespino/cloudberry/actions/runs/11943779438
> > > > > > >-
> > > https://github.com/edespino/cloudberry/actions/runs/11943000112
> > > > > > >
> > > > > > > However, I've noticed some inconsistencies in other test suites
> > > > during
> > > > > > this
> > > > > > > investigation. I would appreciate if you all could review these
> > > > results
> > > > > > and
> > > > > > > provide feedback on the increased shared memory solution and
> any
> > > > > insights
> > > > > > > into the inconsistent test results observed in other suites.
> > > > > > > Thank you,
> > > > > > > -=e
> > > > > > > --
> > > > > > > Ed Espino
> > > > > > > Apache Cloudberry (incubating) & MADlib
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Ed Espino
> > > > >
> > > >
> > >
> > >
> > > --
> > > Ed Espino
> > > Apache Cloudberry (incubating) & MADlib
> > >
> >
>
>
> --
> Ed Espino
> Apache Cloudberry (incubating) & MADlib
>

Re: HEADS UP: Apache Cloudberry Workflow build issue

[Max Yang]

Awesome~

On Wed, Nov 20, 2024 at 7:08 PM Ed Espino  wrote:

> Please rebase your branches to get the latest workflow build fix from main.
>
> PR #719 has been merged: https://github.com/apache/cloudberry/pull/719
>
> -=e
>
> On Wed, Nov 20, 2024 at 12:59 AM Ed Espino  wrote:
>
> > There is a build issue with the newly added Github Workflow. I have quite
> > easily reproduced it. I am trying to track it down now.
> >
> > Sorry for the inconvenience,
> > -=e
> >
> >
> > --
> > Ed Espino
> > Apache Cloudberry (incubating) & MADlib
> >
> >
>
> --
> Ed Espino
> Apache Cloudberry (incubating) & MADlib
>

When to release Cloudberry 2.0

[Max Yang]

Hi All,

We need to consider when to release Cloudberry 2.0, and how often to
release it, which involves the following considerations:
The version number consists of three parts: < major >. < minor >. < patch
>, namely x.y.z.

In the Greenplum release, the bump of major to major version means that
metadata and data are no longer compatible. Users need to upgrade or import
and export data that needs to be displayed. The general release frequency
is several years in Greenplum.
And bump of minor generally includes some feature releases, but it will not
cause data incompatibility.
Bump of patch is usually a bug fix.

We need to consider release candence, especially for major release. After
the general version is released, there is a support lifecycle. Therefore,
when engineers submit code, they need to submit code to different branches
at the same time (such as 5X_STABLE and 6X_STABLE in Greenplum). If there
are too many versions released, users need to upgrade frequently, which is
another cost. This is also why we need to control the cadence of major
version releases.
In the previous roadmap discussion email thread, we mentioned a PostgreSQL
kernel upgrade in the near future. The planned upgrade to PostgreSQL 15.x
will bring a lot of metadata changes to the PostgreSQL kernel upgrade. In
Greenplum, major version release was also with the PostgreSQL kernel
upgrade. Is it a suitable time to wait until the PG 15.x or PG 16.x kernel
upgrade is stable? Welcome to discuss

Re: When to release Cloudberry 2.0

[Max Yang]

Hi Andrey,

Good to see you!!!
Yes, we need to add some checks in codes to let the program automatically
discover incompatible issues.
As for the issue of functional classification, it can be added with
corresponding tags during code review, and the document can be
associated with this information when published?

On Mon, Dec 9, 2024 at 5:01 PM Andrey M. Borodin 
wrote:

>
>
> > On 9 Dec 2024, at 11:26, Max Yang  wrote:
> >
> > Welcome to discuss
>
> Hi!
>
> Let’s consider also Clickhouse versioning.
> Clickhouse version is “year.release.patch”. Also they add tags “stable” or
> “lts” to some releases.
>
> The basic idea is that you have continuous development process not tied to
> specific dates. And make branches for the supported versions, which do not
> receive new destabilizing features. Adjacent releases must be binary
> compatible wrt on-disk data. But we will clearly need a breaking versions
> with catversion and wal file magic bump.
>
> This versioning model is more natural for cloud services. It instantly
> gives a clue to a customer of how outdated the cluster is.
> Also, for a cloud provider it’s good to divide a functionality into tiers:
> something that can be removed in future, something that can have api
> change, something that is stable and recommended for production use.
>
> I’m mostly proposing this as an alternative for a discussion. I don’t have
> strong opinions on which versioning is better. Here you can read more on
> this versioning[0].
>
> Thanks!
>
>
> Best regards, Andrey Borodin.
>
> [0] https://clickhouse.com/docs/en/faq/operations/production
> -
> To unsubscribe, e-mail: dev-unsubscr...@cloudberry.apache.org
> For additional commands, e-mail: dev-h...@cloudberry.apache.org
>
>

Re: When to release Cloudberry 2.0

[Max Yang]

Hi Ed,

Agree that we have the first version 2.0 first, which can help us go
through the entire process
and run the release pipeline.

Generally speaking, the time for the first release will be longer than
later. Thank you for volunteering as the release manager.
Your many experiences will definitely help us, and the engineer will assist
you in doing the relevant work.

On Mon, Dec 9, 2024 at 3:01 PM Ed Espino  wrote:

> Hi Max,
>
> Thank you for raising these important points about release strategy. As
> someone who has volunteered to be Release Manager for our initial Apache
> releases, I'd like to share some thoughts:
>
>1. I strongly agree with your semantic versioning proposal. You've
>outlined it well - major.minor.patch (x.y.z) where major version changes
>indicate breaking changes like metadata/data incompatibility, minor
>versions for feature releases maintaining compatibility, and patch for
> bug
>fixes. Having this clear versioning scheme (semver.org) will help both
>developers and users understand the impact of each release.
>2. Apache projects benefit from regular releases - they demonstrate
>project health and provide opportunities to refine our community
> processes.
>While we need to be thoughtful about major version changes that impact
>users, we shouldn't delay releases unnecessarily.
>3. Regarding branch maintenance (5X_STABLE, 6X_STABLE approach): This
>was challenging even in a commercial setting with dedicated teams. We
>should carefully consider our community's capacity to maintain multiple
>long-term branches before committing to this model.
>4. The PostgreSQL major version upgrade is a significant undertaking. I
>suggest we:
>   - Form a working group specifically for this
>   - Have community members volunteer to lead different aspects
>   - Create a detailed impact assessment
>   - Develop a testing strategy
>   - Document the process for future upgrades
>5. I believe we should proceed with planning a 2.0 release based on our
>current catalog changes and compatibility requirements, independent of
> the
>PG 15.x/16.x upgrade timeline. The PG upgrade will naturally align with
> a
>major version bump when it happens, but shouldn't be a blocker for 2.0
> if
>we have other breaking changes to address.
>
> As a next step, I propose working on our first Apache releases to establish
> our processes. This experience will help us better plan and execute both
> the 2.0 release and future PG version upgrades.
>
> I would like to formally volunteer as Release Manager for the initial
> Apache Cloudberry (Incubating) releases. Having served as Release Manager
> for several Apache projects over the years, I'm familiar with the process
> and requirements. I'm ready to shepherd both the release process and this
> versioning discussion, with the goal of working toward a 2.0 release (given
> our likely incompatibilities) and potentially a 1.6.X release. While we
> still have some process work to complete before we're ready for these
> initial releases, I'm committed to helping drive this forward.
>
> Would others like to share their thoughts on this approach?
>
> Looking forward to the discussion,
> -=e
>
> On Sun, Dec 8, 2024 at 10:26 PM Max Yang  wrote:
>
> > Hi All,
> >
> > We need to consider when to release Cloudberry 2.0, and how often to
> > release it, which involves the following considerations:
> > The version number consists of three parts: < major >. < minor >. < patch
> > >, namely x.y.z.
> >
> > In the Greenplum release, the bump of major to major version means that
> > metadata and data are no longer compatible. Users need to upgrade or
> import
> > and export data that needs to be displayed. The general release frequency
> > is several years in Greenplum.
> > And bump of minor generally includes some feature releases, but it will
> not
> > cause data incompatibility.
> > Bump of patch is usually a bug fix.
> >
> > We need to consider release candence, especially for major release. After
> > the general version is released, there is a support lifecycle. Therefore,
> > when engineers submit code, they need to submit code to different
> branches
> > at the same time (such as 5X_STABLE and 6X_STABLE in Greenplum). If there
> > are too many versions released, users need to upgrade frequently, which
> is
> > another cost. This is also why we need to control the cadence of major
> > version releases.
> > In the previous roadmap discussion email thread, we mentioned a
> PostgreSQL
> > kernel u

Re: WAL-G 3.0.5 released

[Max Yang]

Congratulations for WAL-G and Apache Cloudberry!!

On Mon, Feb 10, 2025 at 2:56 PM Dianjin Wang  wrote:

> Hey,
>
> I would like to forward some great news that the latest WAL-G 3.0.5 has
> added support for Apache Cloudberry!
>
> Best,
> Dianjin Wang
>
>
> -- Forwarded message -
> From: WAL-G via PostgreSQL Announce 
> Date: Thu, Feb 6, 2025 at 9:46 PM
> Subject: WAL-G 3.0.5 released
> To: PostgreSQL Announce 
>
>
>
> WAL-G 3.0.5 released
> The WAL-G team is pleased to announce the release of version 3.0.5 of
> WAL-G.
>
> WAL-G is a tool for archival database restoration for PostgreSQL and
> several other databases.
>
> WAL-G is a tool for restoring archived databases in PostgreSQL and several
> other database systems. Starting with this release, support for Apache
> Cloudberry has also been added. Apache Cloudberry is an open source fork of
> PostgreSQL that is designed for cloud analytics and is based on
> GreenplumDB.
>
> Also, this release fixes bug #1615
>  in *wal-g copy* command for
> PostgreSQL. Copying history between different storages was placing WALs to
> incorrect path. Restoration of such history required manual path fix.
>
> WAL-G v3.0.5 is available for download on our GitHub releases page
> .
>
> Have a nice day!
> This email was sent to you from WAL-G. It was delivered on their behalf by
> the PostgreSQL project. Any questions about the content of the message
> should be sent to WAL-G.
>
> You were sent this email as a subscriber of the *pgsql-announce*
> mailinglist, for the content tag Related Open Source. To unsubscribe from
> further emails, or change which emails you want to receive, please click
> the personal unsubscribe link that you can find in the headers of this
> email, or visit https://lists.postgresql.org/unsubscribe/.
>

Re: Cloudberry Migration to Greenplum without or with minimal downtime

[Max Yang]

Hey

You can try using cbcopy  to
support migration from greenplum to cloudberry database.
Ask directly here if have any questions.

On Tue, Dec 17, 2024 at 7:37 AM M.Yousaf Maqsood 
wrote:

> Hi Team,
>
> I hope you are doing well. What about the best practices to migrate from
> Greenplum 6.20 to Cloudberry without downtime and with minimal downtime.
>
> As cbcopy / backup utility may take longer downtime. It's not best
> practice.
>
> Kind regards,
>
> Muhammad Yousaf Maqsood
>
> Cell# +923134039397
>
> LinkedIn profile: muhammadyousafmaqsood
>

Re: Cloudberry Real time streaming

[Max Yang]

Hey,

You can try the kafka_fdw of Cloudberry version
, the component has been
adapted to cloudberry, can work normally.
If you encounter any problems, you can ask directly.

On Tue, Dec 17, 2024 at 7:37 AM M.Yousaf Maqsood 
wrote:

> Hi Team,
>
> I hope you are doing well. According to the cloudberry documentation,  If
> we talk about real time streaming , like fetching data in real time
> streaming from informix to greenplum.   Can you please share the guide if
> this is possible ?
>
> Kind regards,
>
> Muhammad Yousaf Maqsood
>
> Cell# +923134039397
>
> LinkedIn profile: muhammadyousafmaqsood
>

Re: [Discussion] Proposal for do not cancel APPROVE after PR has been updated

[Max Yang]

Sounds reasonable in some cases. Is it possible to add a special CI skip
cancel instruction if author don't want to cancel APPROVE?

On Thu, Jan 16, 2025 at 5:42 PM jiaqi.zhou  wrote:

> Hi all,
>
>
> I personally have an idea:  we should not cancel approve after PR has been
> updated.
>
>
> 1. After the reviewer approves the PR, the current PR may still need to be
> rebased (do git rebase main or git merge main)
> 2. The approved PR will still run CI once to ensure that the current PR is
> compliant
> 3. If the PR is updated, the reviewer needs to approve it again, which
> wastes the time of both the committer and the reviewer.
>
>
> For example:the reviewer made some minor comments (such as suggestions for
> changing some typo, or the comments that can be rejected) and approved
> current PR. The commiter accepted these suggestions and update the PR.
> After that, reviewer still need click the approve button again (or may need
> to review the PR again). I think this is unreasonable.
>
>
> Thanks
> Jiaqi
>
>
>
>
>
>

Re: [ANNOUNCEMENT] New Committer: Xiong Tong (TomShawn)

[Max Yang]

Congratulations!

On Wed, Mar 19, 2025 at 4:45 PM Ed Espino  wrote:

> Congratulations and Welcome Xiong Tong!
>
> Cheers,
> -=e
>
> On Tue, Mar 18, 2025 at 9:02 PM Dianjin Wang 
> wrote:
>
> > The Podling Project Management Committee (PPMC) for Apache Cloudberry
> > has invited Xiong Tong to become a committer and we are pleased
> > to announce that he has accepted.
> >
> > TomShawn has made significant contributions to the project’s
> documentation
> > over the past two years, which can be reviewed here[1]. His dedication
> > and engagement have been instrumental in shaping the project's
> > documentation efforts.
> >
> > Please join us in welcoming Xiong Tong to his new role and
> > responsibility in our project community.
> >
> > [1] https://github.com/apache/cloudberry-site/commits?author=TomShawn
> >
> > Dianjin Wang
> > On behalf of the Cloudberry PPMC
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cloudberry.apache.org
> > For additional commands, e-mail: dev-h...@cloudberry.apache.org
> >
> >
>
> --
> Ed Espino
> Apache Cloudberry (incubating) & MADlib
>

Re: [DISCUSS] Setting up CI/CD workflows for other Cloudberry repos

[Max Yang]

Good to know if we can enable performance testing.

On Tue, Apr 15, 2025 at 10:02 PM Jianghua Yang  wrote:

> One suggestion is to add a CI pipeline for performance regression testing.
>
> Max Yang  于2025年4月14日周一 23:21写道：
>
> > +1
> >
> > On Tue, Apr 15, 2025 at 1:16 PM Dianjin Wang 
> > wrote:
> >
> > > Hi all,
> > >
> > > I’d like to start a discussion about setting up basic CI/CD workflows
> > > for the other Cloudberry repos under the Apache GitHub organization —
> > > including cloudberry-pxf, cloudberry-gpbackup-s3-plugin,
> > > cloudberry-go-libs, and cloudberry-gpbackup.
> > >
> > > These repos are currently 1–2 years behind their corresponding
> > > Greenplum archived projects, and we’ll need to cherry-pick a number of
> > > commits to bring them up to date. Before diving into that work, it
> > > would be helpful to have CI/CD in place to ensure we can easily verify
> > > changes along the way.
> > >
> > > While this is not a strict requirement for the Cloudberry 2.0 release,
> > > it would be great to kick off this effort soon so that users can more
> > > easily adopt these components as part of their Cloudberry 2.0
> > > deployments.
> > >
> > > Let me know what you think, and feel free to share your feedback.
> > >
> > > Best,
> > > Dianjin Wang
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@cloudberry.apache.org
> > > For additional commands, e-mail: dev-h...@cloudberry.apache.org
> > >
> > >
> >
>

Re: Discussion: Change PAX Plugin to Be Disabled by Default?

[Max Yang]

PAX, as a storage plugin, has been contributed to the community.
Should we turn on pax by default, encourage users to use it more, provide
more feedback to help polish the product, but also provide an option to
turn it off for unwanted users?
We can make submodule init automated to reduce the impact on other users.

Best regards, Max Yang


On Tue, May 6, 2025 at 11:10 AM jiaqi.zhou  wrote:

> Hi all, Wishing you a happy Labor Day.
>
>
>
>
> I DON'T AGREEthat disabling PAX by default is a good idea.
>
>
>
> 1. About "Build Consistency with Other contrib Modules"
>
>
> You may notice that the AO table does not exist as an extension in
> CBDB/GP, which is of course partly for historical reasons. But in fact,
> when we were working on PAX, we had to clean up a lot of AO-specific
> logical in the CBDB kernel. Currently, the AO tables could be modularized
> and move to the contrib/gpcontrib, but we did not do so. PAX was designed
> to replace the AO table, and the current version of PAX has more feature
> than AO and better scalability. It also performed better than the AO table
> in some tests.
>
>
> If you still think that all extension in contrib should disabled, Then
> CBDB will completely serve as a subset of GP.
>
>
> 2. About "Reduce Build Failures"
>
>
> Ed has mentioned compilation improvement suggestions before, and PAX will
> make corresponding compilation changes later.
>
>
> 3. About "Optional Nature of the Feature"
>
>
> Which part do you think is the "core feature"? Although PAX is an optional
> AM function, it is superior to AO table in all aspects. Is there enough
> evidence to show that user don’t need PAX? If we do disabled PAX by
> default, That will make users less aware of what PAX does.
>
>
> Finally, I always think that we should "solve problems when they occur"
> instead of avoiding them. As a new feature, PAX will encounter many
> problems before it matures, and we should not avoid these problems. If we
> just avoid problems blindly, CBDB will become a subset of GP with many
> useless features.
>
>
> Thanks
> Jiaqi
>
> At 2025-04-25 14:23:37, "Dianjin Wang"  wrote:
> >Hi all,
> >
> >I’d like to bring up a point regarding the PAX recently merged into
> >the main branch.
> >
> >Currently, the PAX is enabled by default in configure, and users need
> >to explicitly disable it via `--disable-pax` option. However, this
> >behavior is inconsistent with most of the other extensions under the
> >contrib/ or gpcontrib/ dir, which are typically disabled by default
> >unless explicitly enabled.
> >
> >I believe it would be more user-friendly and consistent to change the
> >default behavior of PAX to disabled, requiring users to opt-in via
> >`--enable-pax`.
> >
> >Here’s why:
> >
> >1. Build Consistency with Other contrib Modules: Most contrib plugins
> >are not enabled by default. Changing PAX to follow this pattern aligns
> >with user expectations, especially for long-time Greenplum users.
> >
> >2. Reduce Build Failures: PAX currently requires downloading several
> >submodules during the build. For users who install Cloudberry from
> >source without prior knowledge of this requirement, this will lead to
> >build failures, which can be confusing and frustrating.
> >
> >3. Optional Nature of the Feature: PAX, while valuable, is not a core
> >feature that every user will need. Letting users opt in to building it
> >makes the installation process simpler for the general case.
> >
> >We can also update the build instructions and documentation to clearly
> >indicate how to enable PAX if needed (--enable-pax) and how to fetch
> >its required submodules.
> >
> >I’d love to hear your thoughts on this. If there’s a consensus, that
> >would be better to make this change before our release 2.0.
> >
> >Best,
> >Dianjin Wang
> >
> >-
> >To unsubscribe, e-mail: dev-unsubscr...@cloudberry.apache.org
> >For additional commands, e-mail: dev-h...@cloudberry.apache.org
>

Re: [DISCUSS] Finalizing Work for Apache Cloudberry (Incubating) 2.0.0 Release

[Max Yang]

Thanks Ed! It's a good place to share information.

On Wed, Apr 23, 2025 at 7:07 PM Ed Espino  wrote:

> Hi all,
>
> As we gear up for the Apache Cloudberry (Incubating) 2.0.0 release,
> I’d like to gather input on any remaining PRs, features, or tasks the
> community would like to see included.
>
> To coordinate efforts, we’re experimenting with a GitHub Project board
> for this release:
>
>   https://github.com/orgs/apache/projects/490
>
> If you’re working on something you’d like to propose for 2.0.0, please
> reply here or link it on the board. This includes code, packaging,
> docs, or testing work.
>
> Reminder: only the signed source release will be official per ASF
> policy. Binaries like Docker images and packages will be tracked
> separately as convenience artifacts.
>
> Thanks in advance for your input and contributions!
>
> Best,
> Ed Espino
> Release Manager – Apache Cloudberry (Incubating) 2.0.0
>

Re: Request to Add Coverity Scan Token to Cloudberry Repo Secrets

[Max Yang]

Awesome!

On Wed, Apr 23, 2025 at 10:28 AM Dianjin Wang  wrote:

> Hi all,
>
> Now the SonarQube workflow has been added to the Cloudberry. You can
> see the scan result here:
> https://sonarcloud.io/summary/new_code?id=apache_cloudberry. If you
> want to help maintain it, welcome to log in to SonarCloud with your
> GitHub account, and I will grant you access. Let me know.
>
> Moreover, the Coverity and SonarQube scans will be running once a week.
>
> Best,
> Dianjin Wang
>
> On Thu, Apr 10, 2025 at 3:37 PM Dianjin Wang 
> wrote:
> >
> > Hi all,
> >
> > There is one PR on adding the SonarQube workflow to the Cloudberry:
> > https://github.com/apache/cloudberry/pull/1004. Need more reviewers to
> > merge it. Appreciate your help!
> >
> > Best,
> > Dianjin Wang
> >
> > On Mon, Mar 24, 2025 at 9:12 PM Dianjin Wang 
> wrote:
> > >
> > > Yes, exactly. Hope we can make use of the tools’ reports.
> > >
> > > On Monday, March 24, 2025, Илья Шипицин  wrote:
> > >>
> > >> previously coverity itself was not very stable and I'd say ~50% of
> scan failed due to coverity issues.
> > >> now it is very stable, likely once a week is fine. It really depends
> on how often you want to look at those reports.
> > >>
> > >> пн, 24 мар. 2025 г. в 12:02, Dianjin Wang :
> > >>>
> > >>> Hi guys,
> > >>>
> > >>> How about changing the Coverity Scan frequency from once a day to
> once
> > >>> a week? We can check the results weekly to see if any changes are
> > >>> needed. If that’s okay, I can create a small PR to update the
> > >>> workflow.
> > >>>
> > >>> I also want to apply for the SonarQube sponsorship for Cloudberry
> > >>> under Apache, which is widely used and will help us gain more
> insights
> > >>> from the static analysis. Let me know what you think.
> > >>>
> > >>> Best,
> > >>> Dianjin Wang
> > >>>
> > >>> On Sat, Mar 22, 2025 at 9:52 AM Dianjin Wang 
> wrote:
> > >>> >
> > >>> > Hi,
> > >>> >
> > >>> > Now the Coverity Scan can run smoothly:
> https://github.com/apache/cloudberry/actions/runs/14003068651. If you
> have any improvments, welcome to create a PR.
> > >>> >
> > >>> > Thanks to @chipitsine for his work.
> > >>> >
> > >>> > On Wednesday, March 19, 2025, Dianjin Wang 
> wrote:
> > >>> >>
> > >>> >> Hi everyone,
> > >>> >>
> > >>> >> Here are the updates on the Coverity Scan for Cloudberry. The ASF
> > >>> >> Infra team has successfully added the secret to the Cloudberry
> > >>> >> repository. One PR on Coverity Scan was also merged on GitHub
> [1], but
> > >>> >> it still requires improvements to run smoothly in GitHub Actions.
> > >>> >>
> > >>> >> You can check the apache/cloudberry to see the scan results:
> > >>> >>
> https://scan.coverity.com/projects/apache-cloudberry-1f6d497c-9dcb-4204-a37b-0d79c6c5bec3
> .
> > >>> >>
> > >>> >> [1] https://github.com/apache/cloudberry/pull/849
> > >>> >>
> > >>> >> Best,
> > >>> >> Dianjin Wang
> > >>> >>
> > >>> >> On Fri, Mar 14, 2025 at 11:33 AM Dianjin Wang 
> wrote:
> > >>> >> >
> > >>> >> > Dear Team,
> > >>> >> >
> > >>> >> > I hope you are doing well.
> > >>> >> >
> > >>> >> > I would like to request your assistance in adding a GitHub
> repository
> > >>> >> > secret for the Apache Cloudberry project. We are integrating
> Coverity
> > >>> >> > Scan into our workflow, and we need to securely store the
> Coverity
> > >>> >> > Scan Token in the GitHub Repo secrets.
> > >>> >> >
> > >>> >> > Could you please help set up a new secret in the
> apache/cloudberry[1]
> > >>> >> > repository with the following details?
> > >>> >> >
> > >>> >> > * Secret Name: COVERITY_SCAN_TOKEN
> > >>> >> > * Secret Value: (I will send the token separately to the Infra
> team
> > >>> >> > member handling this request.)
> > >>> >> >
> > >>> >> > I appreciate your support in setting this up. Thanks!
> > >>> >> >
> > >>> >> > [1] https://github.com/apache/cloudberry
> > >>> >> >
> > >>> >> >
> > >>> >> > Best,
> > >>> >> > Dianjin Wang
> > >>> >
> > >>> >
> > >>> >
> > >>> > --
> > >>> >
> > >>> > Best,
> > >>> > Dianjin Wang
> > >>> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cloudberry.apache.org
> For additional commands, e-mail: dev-h...@cloudberry.apache.org
>
>

Re: [DISCUSS] Setting up CI/CD workflows for other Cloudberry repos

[Max Yang]

+1

On Tue, Apr 15, 2025 at 1:16 PM Dianjin Wang  wrote:

> Hi all,
>
> I’d like to start a discussion about setting up basic CI/CD workflows
> for the other Cloudberry repos under the Apache GitHub organization —
> including cloudberry-pxf, cloudberry-gpbackup-s3-plugin,
> cloudberry-go-libs, and cloudberry-gpbackup.
>
> These repos are currently 1–2 years behind their corresponding
> Greenplum archived projects, and we’ll need to cherry-pick a number of
> commits to bring them up to date. Before diving into that work, it
> would be helpful to have CI/CD in place to ensure we can easily verify
> changes along the way.
>
> While this is not a strict requirement for the Cloudberry 2.0 release,
> it would be great to kick off this effort soon so that users can more
> easily adopt these components as part of their Cloudberry 2.0
> deployments.
>
> Let me know what you think, and feel free to share your feedback.
>
> Best,
> Dianjin Wang
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cloudberry.apache.org
> For additional commands, e-mail: dev-h...@cloudberry.apache.org
>
>

Re: When to release Cloudberry 2.0

[Max Yang]

Hi hackers,

We’re working on contributing the PAX feature and aim to complete it by
March. Since this feature involves catalog changes, we’d like to have it
included in the 2.0 release.
I agree that it’s a good time to start preparing for the 2.0 release.

On Fri, Mar 7, 2025 at 11:36 AM Dianjin Wang  wrote:

> As the first phase of the cherry-pick work nears completion, I believe
> it’s time to start preparing for the Cloudberry 2.0 release as Reshke
> asked earlier this week.
>
> I would like to provide some inputs for consideration from my perspective:
> * High Priority: Cleanup PRs (#731, #812, #920) should be included in
> the 2.0 release for a better codebase and ASF compliance
> * Low Priority: Other ideas that need more feedback (#948, #961, #909)
>
> Additionally, I’ve gathered some requests from community members:
> * Besides providing RPM packages for EL 8/9, will offer .deb packages?
> * How can upgrade from 1.6.0 to 2.0.0? Will there be documentation for
> this?
>
> Thanks! Looking forward to your thoughts!
>
> On Mon, Feb 24, 2025 at 1:56 PM Max Yang  wrote:
> >
> > It's good that we are starting to work on the pg_upgrade now.
> >
> > On Sat, Feb 22, 2025 at 3:23 PM Kirill Reshke  wrote:
> >
> > > On Thu, 30 Jan 2025 at 00:14, Kirill Reshke 
> > > wrote:
> > > >
> > > > I tried gp_upgrade once again today. Our gp 6 fork is here[1].
> > > > Currently, there is some vital work from GP7 missing in CBDB, so I
> did
> > > > a cherry-pick PR [2]. Most probably, gpupgrade  will need some more
> > > > attention after [2] merged, this is what I'm currently working on.
> > > >
> > > > [1] https://github.com/open-gpdb/gpupgrade
> > > > [2] https://github.com/apache/cloudberry/pull/898
> > > >
> > >
> > > Today I was hacking a new set of pg_upgrade cherry-picks [0]. While
> > > doing so, I discovered that Apache Cloudberry (CDBD) has basically no
> > > CI for pg_upgrade (and thus, gp_upgrade). I believe this open source
> > > project should derive the best service and experience to its community
> > > and users, and thus we need to begin supporting gp_upgrade scenarios
> > > (or, at least, activity in that direction). This includes, at very
> > > least, CDBD to CDBD binary upgrade support. In ideal case, with
> > > release of CDBD there will be support for 1.6 to 2.0 binary upgrade
> > > using gp_upgrade, along with comprehensive instructions on how to
> > > handle specific problems. I am aware that this is overly optimistic,
> > > though.
> > >
> > > I'll keep working in this direction, attempting to engage as many
> > > engineer resources (other pg/cbdb hackers) as possible. I cannot,
> > > however, promise that I will be successful here by the release of 2.0.
> > >
> > > [0] https://github.com/apache/cloudberry/pull/955
> > >
> > > --
> > > Best regards,
> > > Kirill Reshke
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@cloudberry.apache.org
> > > For additional commands, e-mail: dev-h...@cloudberry.apache.org
> > >
> > >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cloudberry.apache.org
> For additional commands, e-mail: dev-h...@cloudberry.apache.org
>
>

Re: Join OSPP 2025 – Engage Students in Open Source Development

[Max Yang]

It's a good opportunity, everyone who is interested can participate.

On Wed, Mar 12, 2025 at 4:12 PM Dianjin Wang  wrote:

> Hi all,
>
> The Open Source Promotion Plan (OSPP) 2025 is now open for community
> registration. Similar to Google Summer of Code, OSPP aims to encourage
> university students worldwide to participate in open-source
> development. As part of this program, our committers can propose
> project ideas for students to apply and contribute to.
>
> I’ve previously helped other Apache projects with OSPP, and some of
> the participating students later became active contributors. This
> year, I’d like to help our Cloudberry community register for the
> program. Since we’re new to OSPP, I’m not sure how many task slots
> we’ll get, but let’s give it a try!
>
> You can learn more about OSPP from the following links:
>
> [1] Official Website: https://summer-ospp.ac.cn/
> [2] FAQ: https://blog-en.summer-ospp.ac.cn/archives/FAQ
>
> Looking forward to your thoughts and participation!
>
> Best,
> Dianjin Wang
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cloudberry.apache.org
> For additional commands, e-mail: dev-h...@cloudberry.apache.org
>
>

Re: Exciting News – ASF Membership Invitation

[Max Yang]

Congrats!

On Wed, Mar 12, 2025 at 10:17 AM LOUIS MUGNANO  wrote:

> Hi Ed,
>
> Congratulations! This is an outstanding achievement and a testament to your
> hard work and dedication. It's very well deserved.
>
> Louis Mugnano
> Mugnano-Data-Consulting-llc
> 843-580-6223
> https://www.mugnanodc.com
>
> On Fri, Mar 7, 2025 at 6:22 PM Ed Espino  wrote:
>
> > Team,
> >
> > I’m excited to share that I’ve been invited to join *The Apache Software
> > Foundation (ASF) as a Member*! This is a significant milestone, as ASF
> > Membership is by invitation only and recognizes sustained contributions
> to
> > the foundation and its projects.
> >
> > A big thanks to *Roman Shaposhnik* for advocating for me—it’s an honor to
> > be part of ASF at this level. Looking forward to continuing to contribute
> > and represent our work within the broader Apache community!
> >
> > Cheers,
> > -=e
> > --
> > Ed Espino
> > Apache Cloudberry (Incubating) & MADlib
> >
>

Re: When to release Cloudberry 2.0

[Max Yang]

It's good that we are starting to work on the pg_upgrade now.

On Sat, Feb 22, 2025 at 3:23 PM Kirill Reshke  wrote:

> On Thu, 30 Jan 2025 at 00:14, Kirill Reshke 
> wrote:
> >
> > I tried gp_upgrade once again today. Our gp 6 fork is here[1].
> > Currently, there is some vital work from GP7 missing in CBDB, so I did
> > a cherry-pick PR [2]. Most probably, gpupgrade  will need some more
> > attention after [2] merged, this is what I'm currently working on.
> >
> > [1] https://github.com/open-gpdb/gpupgrade
> > [2] https://github.com/apache/cloudberry/pull/898
> >
>
> Today I was hacking a new set of pg_upgrade cherry-picks [0]. While
> doing so, I discovered that Apache Cloudberry (CDBD) has basically no
> CI for pg_upgrade (and thus, gp_upgrade). I believe this open source
> project should derive the best service and experience to its community
> and users, and thus we need to begin supporting gp_upgrade scenarios
> (or, at least, activity in that direction). This includes, at very
> least, CDBD to CDBD binary upgrade support. In ideal case, with
> release of CDBD there will be support for 1.6 to 2.0 binary upgrade
> using gp_upgrade, along with comprehensive instructions on how to
> handle specific problems. I am aware that this is overly optimistic,
> though.
>
> I'll keep working in this direction, attempting to engage as many
> engineer resources (other pg/cbdb hackers) as possible. I cannot,
> however, promise that I will be successful here by the release of 2.0.
>
> [0] https://github.com/apache/cloudberry/pull/955
>
> --
> Best regards,
> Kirill Reshke
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cloudberry.apache.org
> For additional commands, e-mail: dev-h...@cloudberry.apache.org
>
>

Re: Discussion: Change PAX Plugin to Be Disabled by Default?

[Max Yang]

Thanks for repeated discussions and feedback. More people still prefer not
to compile PAX by default, so we do not compile PAX by default.

Once again thank you all.

Best regards, Max Yang


On Sat, May 10, 2025 at 11:15 PM Jianghua Yang  wrote:

> For our current use case, I’d like to minimize the Pax build to reduce
> dependencies and avoid unnecessary components. Specifically, I’ve disabled
> the following CMake options:
> option(USE_MANIFEST_API "Use manifest API" OFF)
> option(USE_PAX_CATALOG "Use manifest API, by pax impl" OFF)
> option(BUILD_GTEST "Build with Google Test" OFF)
> option(BUILD_GBENCH "Build with Google Benchmark" OFF)
> option(BUILD_TOOLS "Build with Pax tools" OFF)
>
> This configuration allows us to build only the core modules without pulling
> in submodules or extra third-party libraries. Please let me know if any
> additional flags should be adjusted for this lightweight setup.
>
> Leonid Borchuk  于2025年5月10日周六 07:25写道：
>
> > Hi, all
> >
> > I really like the PostgreSQL approach - configure && make && make
> install.
> > And usually there are no additional packages or builds required.
> Postgresql
> > seems to be compiled everywhere - even on coffee machine. It would be
> great
> > to see the same for cloudberry. Since PAX is quite complex feature it
> would
> > be better to have a special option --enable-pax.
> >
> > I believe we will continue to create RPM and DEB packages with all
> features
> > enabled, so users can take precompiled binaries and start using PAX from
> > scratch.
> >
> > But for those who want to contribute, they can easily compile their first
> > binary and then enable features step by step.
> >
> > On Fri, May 9, 2025 at 11:05 AM Dianjin Wang 
> > wrote:
> >
> > > Hi Jiaqi and all,
> > >
> > > Thanks for your reply and for sharing your insights. I’d like to
> > > respond with a few thoughts from a community and release readiness
> > > perspective.
> > >
> > > 1. Lack of transparency in introducing the PAX
> > >
> > > While I fully respect the engineering efforts behind PAX, we must also
> > > reflect on how the feature was introduced. There was no public design
> > > proposal or open discussion prior to its contribution. The PR was open
> > > for a few weeks, but it was too large to review effectively. The goals
> > > behind PAX might be well-understood within certain internal teams, but
> > > not yet widely discussed in the Cloudberry community. At that time, we
> > > rushed to merge it into the main branch to catch up with the release -
> > > I also gave my +1 to the related PRs.
> > >
> > > This is a valuable lesson for all of us — especially for large,
> > > impactful features, we need more transparency and community
> > > discussion, just like the ongoing one around perfmon[1]. I'm not meant
> > > to blame anyone, it's one part of the story of incubation.
> > >
> > > The key point is that the default enabling behaviour of PAX is also
> > > against the description in the doc[2]. This is why we have this
> > > discussion thread. I have created one PR on setting the PAX to be
> > > disabled by default[3]. Compared to the thousands of file changes in
> > > PAX, mine is too small, however, we have such a deep conversation
> > > here, quite interesting and proud.
> > >
> > > 2. PAX is enabled by default is beyond the users' expectations for now
> > >
> > > The concern is not whether PAX is valuable — it’s about how users
> > > perceive and experience it.
> > >
> > > Having PAX enabled by default breaks the general expectation from most
> > > users familiar with Greenplum or PostgreSQL. We must admit that most
> > > of Cloudberry users will be ones who migrate from the open-source
> > > Greenplum. This difference can lead to:
> > >
> > > * Confusing build failures
> > > * Extra burden on users' Cloudberry installation
> > > * Frustration during first-time installation, which may cause them to
> > > give up on Cloudberry entirely
> > >
> > > Already saw the failure happening from the PPMC members, I bet it will
> > > be the same for the general users, we can imagine that.
> > >
> > > Our goal is to help PAX mature through community feedback. The best
> > > way is to make it opt-in — let users choose to enable it, experiment
> > > with it, and report issues, rather t

Re: [ANNOUNCEMENT] New Committer: Xun Gong

[Max Yang]

Congratulations~

Best regards, Max Yang


On Wed, Jul 9, 2025 at 11:57 AM Lirong Jian  wrote:

> Congratulations, Xun Gong!
>
> Lirong
>
>
> Dianjin Wang  于2025年7月9日周三 11:31写道：
>
> > Hi Jiaqi,
> >
> > Thanks for the announcement! That's great news. Congratulations to Xun
> > Gong on becoming a committer, and welcome to the team!
> >
> > Best,
> > Dianjin Wang
> >
> > On Wed, Jul 9, 2025 at 11:09 AM jiaqi.zhou  wrote:
> > >
> > > The Podling Project Management Committee (PPMC) for Apache Cloudberry
> > > has invited Xun Gong to become a committer and we are pleased
> > > to announce that he has accepted.
> > >
> > >
> > > Based on his contributions in the past two years, Xun Gong  has made
> > significant contributions to the project’s features.
> > >
> > >
> > > Some contributions are as follows:
> > > 1. One of the main developers of PAX, including the development of
> > functions such as clutser,wal log,meta ...
> > > 2. Some development on WAL log.
> > > 3. resolved the Performance issues in hash aggregation.
> > >
> > >
> > > Please join us in welcoming Xun Gong to his new role and
> > > responsibility in our project community.
> > >
> > >
> > > Jiaqi
> > > On behalf of the Cloudberry PPMC
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cloudberry.apache.org
> > For additional commands, e-mail: dev-h...@cloudberry.apache.org
> >
> >
>

Re: [VOTE] Release Apache Cloudberry (Incubating) 2.0.0-rc2

[Max Yang]

Update with +1 (binding).

Best regards, Max Yang


On Mon, Jun 30, 2025 at 12:00 PM Dianjin Wang  wrote:

> +1 (binding). Nice work!
>
> [x] Download links are valid and accessible.
> [x] PGP signature is valid for the release artifact using the KEYS file.
> [x] SHA512 checksums are correct and verified.
> [x] Source release artifact filename includes "incubating".
> [x] LICENSE, NOTICE, and DISCLAIMER files exist and are accurate.
> [x] No unexpected binary files in the source release.
> [x] All source files have appropriate ASF headers (excluding generated
> files and legacy files).
> [x] Build completes successfully from source with clear instructions.
>
> By the way, since the last 2.0 RC1, a few updates have been added to
> the main branch, such as supporting building Cloudberry with PAX using
> the default g++ 8.5 in Rocky 8. Hope we can have the 2.1 release soon
> to include them!
>
> Thanks again!
>
> Best,
> Dianjin Wang
>
> On Mon, Jun 30, 2025 at 7:39 AM Ed Espino  wrote:
> >
> > Hi all,
> >
> > I would like to call a VOTE to release Apache Cloudberry (Incubating)
> > 2.0.0-rc2 — the first official Apache release since the project entered
> > incubation.
> >
> > While the community has produced releases prior to joining the Apache
> > Software Foundation, this is our first release under the ASF's
> governance,
> > following the official Apache release process and incorporating all
> > relevant legal, licensing, and distribution requirements.
> >
> > ---
> >
> > Key changes since 2.0.0-incubating-rc1:
> > - Set Maven pom.xml project version to 2.0.0-incubating
> > - Update version string from 2.0.0-incubating-rc1 to 2.0.0-incubating
> > - Add configure-time check for protobuf, zstd, cmake when --enable-pax is
> > specified
> > - Add the notice to greenplum-path* scripts
> >
> > ---
> >
> > Release Candidate Artifacts
> >
> > Staged release artifacts:
> >
> https://dist.apache.org/repos/dist/dev/incubator/cloudberry/2.0.0-incubating-rc2/
> >
> > Git tag:
> > https://github.com/apache/cloudberry/releases/tag/2.0.0-incubating-rc2
> >
> > Commit:
> >
> https://github.com/apache/cloudberry/commit/868c4694f4c70203b7a7235c2db8346de98f08c0
> >
> > PGP signature key:
> > 3B90B5634E4506F05BA51F2FC9604135C07CD12A — Ed Espino (esp...@apache.org)
> >
> > KEYS file:
> > https://dist.apache.org/repos/dist/dev/incubator/cloudberry/KEYS
> >
> > How to Vote
> > Please review the release and cast your vote below. If you are a PPMC
> > member, please indicate whether your vote is binding.
> >
> > [ ] +1 Approve the release
> > [ ]  0 No opinion
> > [ ] -1 Disapprove (please explain why)
> >
> > The vote will remain open until Thursday, July 3, 2025 at 00:00 UTC.
> >
> > Checklist for reference:
> >
> > [ ] Download links are valid and accessible.
> > [ ] PGP signature is valid for the release artifact using the KEYS file.
> > [ ] SHA512 checksums are correct and verified.
> > [ ] Source release artifact filename includes "incubating".
> > [ ] LICENSE, NOTICE, and DISCLAIMER files exist and are accurate.
> > [ ] No unexpected binary files in the source release.
> > [ ] All source files have appropriate ASF headers (excluding generated
> > files and legacy files).
> > [ ] Build completes successfully from source with clear instructions.
> >
> > PGP Signature and SHA512 checksums Verification Instructions
> >
> > Please refer to our step-by-step guide:
> >
> https://github.com/apache/cloudberry/wiki/Apache-PGP-Signature-and-SHA512-Checksum-Verification
> >
> > About Convenience Binaries
> >
> > As this is our initial release under the Apache Software Foundation, we
> are
> > not providing any convenience binaries (such as .rpm, .deb, or Docker
> > images) as part of this vote. The official release consists solely of the
> > source artifacts linked above.
> >
> > We will be gathering input from the development community on which
> > convenience binaries would be most useful and plan to make them available
> > in the near future via appropriate non-release channels.
> >
> > Please note: any such convenience binaries will not be official ASF
> > releases and will be clearly labeled as such, in accordance with ASF
> policy.
> >
> > ---
> >
> > Thanks for reviewing and voting!
> >
> > Best,
> > -=Ed Espino
> > (on behalf of the Apache Cloudberry (Incubating) community)
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cloudberry.apache.org
> For additional commands, e-mail: dev-h...@cloudberry.apache.org
>
>

Re: [VOTE] Release Apache Cloudberry (Incubating) 2.0.0-rc2

[Max Yang]

 +1. Awesome!

Best regards, Max Yang


On Mon, Jun 30, 2025 at 12:00 PM Dianjin Wang  wrote:

> +1 (binding). Nice work!
>
> [x] Download links are valid and accessible.
> [x] PGP signature is valid for the release artifact using the KEYS file.
> [x] SHA512 checksums are correct and verified.
> [x] Source release artifact filename includes "incubating".
> [x] LICENSE, NOTICE, and DISCLAIMER files exist and are accurate.
> [x] No unexpected binary files in the source release.
> [x] All source files have appropriate ASF headers (excluding generated
> files and legacy files).
> [x] Build completes successfully from source with clear instructions.
>
> By the way, since the last 2.0 RC1, a few updates have been added to
> the main branch, such as supporting building Cloudberry with PAX using
> the default g++ 8.5 in Rocky 8. Hope we can have the 2.1 release soon
> to include them!
>
> Thanks again!
>
> Best,
> Dianjin Wang
>
> On Mon, Jun 30, 2025 at 7:39 AM Ed Espino  wrote:
> >
> > Hi all,
> >
> > I would like to call a VOTE to release Apache Cloudberry (Incubating)
> > 2.0.0-rc2 — the first official Apache release since the project entered
> > incubation.
> >
> > While the community has produced releases prior to joining the Apache
> > Software Foundation, this is our first release under the ASF's
> governance,
> > following the official Apache release process and incorporating all
> > relevant legal, licensing, and distribution requirements.
> >
> > ---
> >
> > Key changes since 2.0.0-incubating-rc1:
> > - Set Maven pom.xml project version to 2.0.0-incubating
> > - Update version string from 2.0.0-incubating-rc1 to 2.0.0-incubating
> > - Add configure-time check for protobuf, zstd, cmake when --enable-pax is
> > specified
> > - Add the notice to greenplum-path* scripts
> >
> > ---
> >
> > Release Candidate Artifacts
> >
> > Staged release artifacts:
> >
> https://dist.apache.org/repos/dist/dev/incubator/cloudberry/2.0.0-incubating-rc2/
> >
> > Git tag:
> > https://github.com/apache/cloudberry/releases/tag/2.0.0-incubating-rc2
> >
> > Commit:
> >
> https://github.com/apache/cloudberry/commit/868c4694f4c70203b7a7235c2db8346de98f08c0
> >
> > PGP signature key:
> > 3B90B5634E4506F05BA51F2FC9604135C07CD12A — Ed Espino (esp...@apache.org)
> >
> > KEYS file:
> > https://dist.apache.org/repos/dist/dev/incubator/cloudberry/KEYS
> >
> > How to Vote
> > Please review the release and cast your vote below. If you are a PPMC
> > member, please indicate whether your vote is binding.
> >
> > [ ] +1 Approve the release
> > [ ]  0 No opinion
> > [ ] -1 Disapprove (please explain why)
> >
> > The vote will remain open until Thursday, July 3, 2025 at 00:00 UTC.
> >
> > Checklist for reference:
> >
> > [ ] Download links are valid and accessible.
> > [ ] PGP signature is valid for the release artifact using the KEYS file.
> > [ ] SHA512 checksums are correct and verified.
> > [ ] Source release artifact filename includes "incubating".
> > [ ] LICENSE, NOTICE, and DISCLAIMER files exist and are accurate.
> > [ ] No unexpected binary files in the source release.
> > [ ] All source files have appropriate ASF headers (excluding generated
> > files and legacy files).
> > [ ] Build completes successfully from source with clear instructions.
> >
> > PGP Signature and SHA512 checksums Verification Instructions
> >
> > Please refer to our step-by-step guide:
> >
> https://github.com/apache/cloudberry/wiki/Apache-PGP-Signature-and-SHA512-Checksum-Verification
> >
> > About Convenience Binaries
> >
> > As this is our initial release under the Apache Software Foundation, we
> are
> > not providing any convenience binaries (such as .rpm, .deb, or Docker
> > images) as part of this vote. The official release consists solely of the
> > source artifacts linked above.
> >
> > We will be gathering input from the development community on which
> > convenience binaries would be most useful and plan to make them available
> > in the near future via appropriate non-release channels.
> >
> > Please note: any such convenience binaries will not be official ASF
> > releases and will be clearly labeled as such, in accordance with ASF
> policy.
> >
> > ---
> >
> > Thanks for reviewing and voting!
> >
> > Best,
> > -=Ed Espino
> > (on behalf of the Apache Cloudberry (Incubating) community)
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cloudberry.apache.org
> For additional commands, e-mail: dev-h...@cloudberry.apache.org
>
>