Re: Review Request - Upgrade Doc

2025-06-23 Thread Alwin Tang
Hi all,

Just wanted to follow up on the recent discussions about the cloudberry 2.0
upgrade. To close the loop, the migration and upgrade documentation has
been approved and published.

It’s available here:
https://cloudberry.apache.org/docs/sys-admin/migration-and-upgrade/

Thanks to @tuhaihe and @robertmu for their review and feedback.

Cheers,
+ Alwin

Alwin Tang  于2025年6月12日周四 20:23写道:

> Hi all,
>
> As we approach the upcoming Cloudberry 2.0.0 release, we’ve prepared a new
> document to guide user upgrading from previous CBDB versions or migrating
> from Greenplum Database.
>
> The document is available here:
> https://github.com/apache/cloudberry-site/pull/287
>
> Your valuable feedback will be highly appreciated.
>
> Thanks!
>
> + Alwin
>


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

2025-06-23 Thread Dianjin Wang
For issue #1148, one PR needs review and approval:
https://github.com/apache/cloudberry/pull/1151.

Best,
Dianjin Wang

On Mon, Jun 9, 2025 at 10:06 AM Ed Espino  wrote:
>
> -1 (binding) — from the Release Manager
>
> As the release manager for Apache Cloudberry (Incubating) 2.0.0 RC1, I am
> casting a binding -1 due to two release-blocking issues identified during
> RC review and platform testing.
>
> What’s been verified:
>
>-
>
>Signatures and SHA512 checksums validate correctly
>-
>
>LICENSE, NOTICE, and DISCLAIMER files are present and appropriate
>-
>
>No binary or compiled artifacts are bundled in the source release
>-
>
>Apache RAT executed successfully using Maven (used only for license
>audit)
>-
>
>Functional testing and CLI output behave as expected
>-
>
>Build tested successfully across the following platforms:
>-
>
>   Rocky Linux 9
>   -
>
>   Ubuntu 22.04 LTS
>   -
>
>   Amazon Linux 2023
>   -
>
>   openSUSE Leap 15.5
>
> Blocking Issue 1: Trademark Compliance – greenplum_path.sh and
> generate-greenplum-path.sh
>
> The source release includes a user-visible script named greenplum_path.sh,
> which is generated by gpMgmt/bin/generate-greenplum-path.sh during
> installation. These filenames include the Greenplum trademark (owned by
> Broadcom Inc.) and are active parts of the install process.
>
> ASF policy prohibits the use of third-party trademarks in filenames or
> output unless clearly justified and disclaimed. These files may imply
> affiliation or endorsement, which is not permitted.
>
> This issue is tracked at:
> https://github.com/apache/cloudberry/issues/1149
>
> Blocking Issue 2: Build Failure with --enable-pax
>
> When building with the --enable-pax configuration option, the build fails
> if the protobuf development environment is not available. The failure is
> not detected during configure, and this leads to an unclear build
> experience.
>
> This issue is tracked at:
> https://github.com/apache/cloudberry/issues/1148
>
> Next Steps:
>
> I will re-roll RC2 once:
>
>-
>
>These two issues are resolved
>-
>
>Installer and build behavior is confirmed across tested platforms
>-
>
>Community consensus has been reached
>
> Request for community input:
>
> Before I proceed with RC2, I welcome feedback from PMC members and
> contributors:
>
>-
>
>Do you agree that the trademarked filenames must be renamed for
>compliance?
>-
>
>Are there any other considerations we should account for before
>preparing RC2?
>
> Thank you all for your continued review and support. Apologies again for
> not catching these issues earlier in the process.
>
> -=e
> (Release Manager, Apache Cloudberry (Incubating))
>
> On Fri, Jun 6, 2025 at 12:59 AM Ed Espino  wrote:
>
> > Hi all,
> >
> > I would like to call a VOTE to release Apache Cloudberry (Incubating) 
> > 2.0.0-rc1 — 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.
> >
> > ---
> >
> > Release Candidate Artifacts
> >
> > Staged release 
> > artifacts:https://dist.apache.org/repos/dist/dev/incubator/cloudberry/2.0.0-incubating-rc1/
> >
> > Git 
> > tag:https://github.com/apache/cloudberry/releases/tag/2.0.0-incubating-rc1
> >
> > Commit:https://github.com/apache/cloudberry/commit/ce1fc9438989ac22146c1c7e483933f3560e6572
> >
> > 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 is open for at least 72 hours and will close no earlier than June 
> > 8, 2025 at 08: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-Signa

[D] [PR] Improve Postgres Binary Performance by Static Linking (PR #1064)

2025-06-23 Thread Xun Gong
Hi all,

I would like to share some context regarding PR #1064 
: “chore: compile postgres 
statically to reduce the PLT function call”.

Background and Motivation

During recent TPC-DS benchmark tests on CloudberryDB, we observed that linking 
the postgres binary against libpostgres.so (the shared library) introduces 
overhead due to Procedure Linkage Table (PLT) function calls. 

This overhead was particularly noticeable in large-scale queries, resulting in 
5-8% lower performance compared to a statically linked binary.

Main Changes

Static Linking:
The PR changes the build process to statically link all *.o object files into 
the postgres binary by default, instead of linking against libpostgres.so. This 
reduces PLT overhead and improves runtime performance.
Configurable Linking:
To preserve user flexibility, a new --link-postgres-with-shared configure 
option is introduced. Users can explicitly choose whether to link postgres with 
the shared library or with object files, independent of whether libpostgres.so 
is built (which remains necessary for certain extensions).
Extension Compatibility:
The build system ensures that extensions like pax, which require 
libpostgres.so, remain compatible. When building such extensions, the system 
checks that the shared backend option is enabled.
Test Infrastructure Improvements:
The PR also migrates certain CI tests (like ic-cbdb-parallel) to use release 
builds instead of debug builds to avoid disk space issues, as statically linked 
binaries are significantly larger.
Performance Impact

Performance results from a 1TB TPC-DS run show that static linking reduces 
overall query duration by 5-8%. This improvement is mainly attributed to the 
reduction in PLT function call overhead.

Compatibility and Usability

By default, the static linking behavior matches Greenplum's approach.
The new configure flag allows users to select their preferred linking method 
without sacrificing extension compatibility.
Known Issues

Statically linked binaries are much larger (e.g., postgres binary size grows 
from <100KB to over 180MB), which may lead to disk space concerns in CI or 
constrained environments.
The PR addresses this by moving CI tests to use the smaller release binaries.
If you have feedback or further suggestions, please review the PR or reply to 
this thread!

Bests,

Xun Gong

Blog Post: Apache Cloudberry 2.0 Preview

2025-06-23 Thread Dianjin Wang
Hi all,

We’re preparing to publish a blog post later this week to introduce
and highlight the key features and improvements in the upcoming Apache
Cloudberry 2.0 (Incubating) release. As our first release since
joining the Apache Incubator, this version brings major updates in
codebase cleanup, branding, new features, CI/CD, security, and
compliance.

The goal of this blog post is to give both the community and the
broader audience a high-level preview of what’s coming in 2.0 and to
build awareness ahead of the official release.

This is not a replacement for the release notes—it’s intended to
provide a concise overview rather than a detailed changelog.

You can preview the draft here:
https://github.com/apache/cloudberry-site/pull/292

If you have any feedback or suggestions, feel free to reply to this
thread or leave comments on GitHub.

Thanks!

Best,
Dianjin Wang

-
To unsubscribe, e-mail: dev-unsubscr...@cloudberry.apache.org
For additional commands, e-mail: dev-h...@cloudberry.apache.org



[DISCUSS] Phased plan for renaming “greenplum_*” scripts in Cloudberry

2025-06-23 Thread Dianjin Wang
Hi all,

Our ongoing discussion about renaming the filenames
`greenplum_path.sh` & `generate-greenplum-path` files (GitHub Issue
#1149[1], PR #1156[2]) has revealed important legal and community
considerations worth summarizing and discussing before proceeding.

## Background

Here’s an updated summary of the situation:

1. Trademark ownership update

Cloudberry evolves from the open-source Greenplum Database. Since
Broadcom Inc. acquired VMware, “Greenplum®” is now a registered
trademark owned by Broadcom.

2. Files in question

Two installation scripts currently include “greenplum” in their filenames:
 - greenplum_path.sh
 - gpMgmt/bin/generate-greenplum-path.sh

These files are part of the user-visible and executable interface and
were flagged during our 2.0.0 RC1 release review, which will be at the
risk of potential legal issues, and may also be a blocker for our
graduation from the ASF incubator.

Some PPMC members and contributors have shared feedback on this matter
- thanks for all the valuable input. To further clarify the legal
perspective, I also created a JIRA ticket to request advice from the
ASF legal team[3]. The legal guidance supports renaming the files but
also suggests a phased approach to avoid breaking compatibility for
existing users. Key recommendations include:

* Adding headers in scripts clarifying the legacy naming usage and
trademark attribution
* Printing warnings when the scripts are invoked
* Communicating with users ahead of the renaming, while renaming —
ideally in a later release

## Proposal: Phased Approach

Given the feedback and advice, the following is the phased approach on
this matter:

1. Phase 1 – Cloudberry 2.0.0

* Add header comments to related files signaling legacy naming and
lack of affiliation with Broadcom Greenplum.
```
These files use the term 'greenplum' to maintain compatibility with
original versions of Apache Cloudberry, which was originally called
Greenplum. This usage does not relate to the VMware Tanzu Greenplum
product, neither do we imply that Apache Cloudberry (Incubating) is
affiliated with, endorsed by, or sponsored by Broadcom Inc.
```
* Modify scripts to emit a runtime warning on usage. (If possible)
* Publish a NOTICE Blog post (on mailing lists and our website)
explaining the change and timeline - We can make the changes in the
Cloudberry 2.1 Release.

2. Phase 2 – Cloudberry 2.1

* Rename files to Cloudberry* names (e.g., cloudberry_env.sh),
removing “greenplum” from user-visible interfaces.
* Clearly document the change in the release note.
Optionally provide compatible aliases in the docs for traditional
Greenplum users, like: `sudo ln -s
/usr/local/cloudberry-db/cloudberry-env.sh
/usr/local/cloudberry-db/greenplum_path.sh`

Benefits of This Plan
* Balance between the traditional user behavior and the coming changes
* Provides transparency to users and downstream consumers
* Ensures full removal of third-party trademark terms before graduation

## Request for Feedback

* Do you agree this phased plan strikes the right balance?
* Any concerns regarding implementation details, user impact, or communication?
* Suggested warning messages, blog format, or alias strategy?

Requesting your thoughts before committing to PRs.

Thanks for your input!

[1] https://github.com/apache/cloudberry/issues/1149
[2] https://github.com/apache/cloudberry/pull/1156
[3] https://issues.apache.org/jira/browse/LEGAL-703

Best,
Dianjin Wang

-
To unsubscribe, e-mail: dev-unsubscr...@cloudberry.apache.org
For additional commands, e-mail: dev-h...@cloudberry.apache.org



Re: [DISCUSS] Phased plan for renaming “greenplum_*” scripts in Cloudberry

2025-06-23 Thread Ed Espino
+1

Thanks, Dianjin, for the clear summary and thoughtful proposal.

I support the phased approach for the following reasons:

- It addresses ASF legal guidance while minimizing disruption to users
familiar with the legacy tooling.
- The runtime warning and blog post provide transparency and early notice
to downstream consumers.
- Renaming in 2.1 aligns with our goal of full ASF compliance before
graduation, without forcing abrupt changes in 2.0.0.
- Providing symlink-based aliases is a practical bridge for traditional
users migrating scripts and habits.

This approach strikes the right balance between legal, technical, and
community considerations.

Best,
Ed Espino

On Mon, Jun 23, 2025 at 12:19 AM Dianjin Wang  wrote:

> Hi all,
>
> Our ongoing discussion about renaming the filenames
> `greenplum_path.sh` & `generate-greenplum-path` files (GitHub Issue
> #1149[1], PR #1156[2]) has revealed important legal and community
> considerations worth summarizing and discussing before proceeding.
>
> ## Background
>
> Here’s an updated summary of the situation:
>
> 1. Trademark ownership update
>
> Cloudberry evolves from the open-source Greenplum Database. Since
> Broadcom Inc. acquired VMware, “Greenplum®” is now a registered
> trademark owned by Broadcom.
>
> 2. Files in question
>
> Two installation scripts currently include “greenplum” in their filenames:
>  - greenplum_path.sh
>  - gpMgmt/bin/generate-greenplum-path.sh
>
> These files are part of the user-visible and executable interface and
> were flagged during our 2.0.0 RC1 release review, which will be at the
> risk of potential legal issues, and may also be a blocker for our
> graduation from the ASF incubator.
>
> Some PPMC members and contributors have shared feedback on this matter
> - thanks for all the valuable input. To further clarify the legal
> perspective, I also created a JIRA ticket to request advice from the
> ASF legal team[3]. The legal guidance supports renaming the files but
> also suggests a phased approach to avoid breaking compatibility for
> existing users. Key recommendations include:
>
> * Adding headers in scripts clarifying the legacy naming usage and
> trademark attribution
> * Printing warnings when the scripts are invoked
> * Communicating with users ahead of the renaming, while renaming —
> ideally in a later release
>
> ## Proposal: Phased Approach
>
> Given the feedback and advice, the following is the phased approach on
> this matter:
>
> 1. Phase 1 – Cloudberry 2.0.0
>
> * Add header comments to related files signaling legacy naming and
> lack of affiliation with Broadcom Greenplum.
> ```
> These files use the term 'greenplum' to maintain compatibility with
> original versions of Apache Cloudberry, which was originally called
> Greenplum. This usage does not relate to the VMware Tanzu Greenplum
> product, neither do we imply that Apache Cloudberry (Incubating) is
> affiliated with, endorsed by, or sponsored by Broadcom Inc.
> ```
> * Modify scripts to emit a runtime warning on usage. (If possible)
> * Publish a NOTICE Blog post (on mailing lists and our website)
> explaining the change and timeline - We can make the changes in the
> Cloudberry 2.1 Release.
>
> 2. Phase 2 – Cloudberry 2.1
>
> * Rename files to Cloudberry* names (e.g., cloudberry_env.sh),
> removing “greenplum” from user-visible interfaces.
> * Clearly document the change in the release note.
> Optionally provide compatible aliases in the docs for traditional
> Greenplum users, like: `sudo ln -s
> /usr/local/cloudberry-db/cloudberry-env.sh
> /usr/local/cloudberry-db/greenplum_path.sh`
>
> Benefits of This Plan
> * Balance between the traditional user behavior and the coming changes
> * Provides transparency to users and downstream consumers
> * Ensures full removal of third-party trademark terms before graduation
>
> ## Request for Feedback
>
> * Do you agree this phased plan strikes the right balance?
> * Any concerns regarding implementation details, user impact, or
> communication?
> * Suggested warning messages, blog format, or alias strategy?
>
> Requesting your thoughts before committing to PRs.
>
> Thanks for your input!
>
> [1] https://github.com/apache/cloudberry/issues/1149
> [2] https://github.com/apache/cloudberry/pull/1156
> [3] https://issues.apache.org/jira/browse/LEGAL-703
>
> Best,
> Dianjin Wang
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cloudberry.apache.org
> For additional commands, e-mail: dev-h...@cloudberry.apache.org
>
>

-- 
Ed Espino