Re: [DISCUSS] Reorganizing the `apache/cloudberry-bootcamp` repo
Cool! Then I need to rethink the way how to reorganize the `cloudberry-bootcamp` better after our `cloudberry-devops-release` move to the main repo. Best, Dianjin Wang On Mon, Jun 9, 2025 at 5:25 PM Ed Espino wrote: > > Hi Leonid, > > Totally agree — let’s move the build scripts into the main repo. > > Having everything in one place will simplify development, especially for > larger changes like PAX support. It’ll streamline testing, reduce > cross-repo friction, and make iteration much faster. We can always revisit > a split setup later if our release needs grow. > > Thanks for raising this — fully on board. > > -=e > > > On Mon, Jun 9, 2025 at 1:47 AM Leonid Borchuk wrote: > > > I totally agree. It would be great to have a single library where all of > > our > > assets are stored. > > > > But until we start large-scale reconstruction work, I would like to ask a > > slightly off-topic question: Why do we even need a > > cloudberry-release-devops? > > Why can't all our scripts be stored in the main repository? > > > > It happens to be rather tedious to use two repos, especially when changing > > something big. Such as adding PAX support. For such a big change you need > > to commit something breaking the building to the main repo. And at that > > point, your tests will fail. Then you have to fix the > > cloudberry-release-devops (add additional packages), but the tests may > > still fail. And now you could fix the tests and make a final commit. And > > only now can one check if everything is OK. We could store all our scripts > > together with the code. > > > > Best regards, Leonid > > > > On Mon, Jun 9, 2025 at 9:05 AM Dianjin Wang wrote: > > > > > Hi all, > > > > > > Over the past two years, the bootcamp repo has grown to include > > > various types of content, such as sandbox Dockerfiles, tutorials, and > > > learning materials. I’d like to start a discussion around reorganizing > > > the `apache/cloudberry-bootcamp` repo to improve clarity and > > > maintainability across our community resources. > > > > > > The primary motivation is to consolidate content by type and reduce > > > redundancy, which would: > > > * Make it easier for contributors to find and update documentation > > > * Reduce ongoing maintenance overhead > > > > > > ## Proposal (for discussion) > > > > > > I propose reorganizing this bootcamp repo as follows: > > > > > > * Move sandbox-related files to `apache/cloudberry-devops-release`, > > > where we maintain tools related to deployment and release automation > > > -- a new dir called `sandbox` will be created to store them. > > > * For the benchmark test files -- a new directory called `benchmark` > > > will be created under `apache/cloudberry-devops-release`, but we can > > > do this until these files are ready. > > > * Migrate tutorials, crash courses, and learning content to the > > > `apache/cloudberry-site` repo, which now serves as the single source > > > for end-user documentation. All of these materials have been copied to > > > our website repo [1]. > > > > > > Once the content has been fully migrated and verified, plan to: > > > > > > * Archive the cloudberry-bootcamp repository, with a notice in the > > > README indicating that it is no longer actively maintained and that > > > the relevant content has been moved. > > > > > > ## Request for Feedback > > > > > > This is just a proposal at this stage. I’d love to hear your thoughts > > > and suggestions. If most of the members agree, I would like to help > > > take action on this plan. > > > > > > Thanks, and looking forward to your feedback! > > > > > > [1] https://cloudberry.apache.org/bootcamp#cloudberry-sandbox > > > > > > Best, > > > Dianjin Wang > > > > > > - > > > 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 - 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-rc1
H Ed, Do you mean that ce1fc9438989ac22146c1c7e483933f3560e6572 is not the final hashtag if RC1 passes, and there will be new commits to replace 2.0.0-incubating-rc1 with 2.0.0-incubating in the source release? If so, the checksum verification step here becomes a variable. Kent Dianjin Wang 于2025年6月9日周一 11:12写道： > Hi Ed, > > Thanks for pointing out these issues. They helped shape a better release. > > 1. For #1149, I admit that the filename change will have a few but not > a significant impact on the traditional user, especially those who > immigrated from Greenplum to Cloudberry. > > I'm not sure if we should add the following text to the disclaimer to > avoid the name change: > > ``` > Greenplum® is a registered trademark of Broadcom Inc. Apache > Cloudberry (Incubating) is not affiliated with, endorsed by, or > sponsored by Broadcom Inc. Any references to Greenplum are for > comparative, educational, and interoperability purposes only. > ``` > > Above is the easiest way. If not, I support the file rename for better > ASF compliance as soon as possible. As per your suggestion, we can > explicitly document these changes in our changelogs. > > Here, we may also need the input from our mentors. > > 2. For #1148, in my opinion, it's not a high-priority issue, but it > would improve the user experience if it could be improved before RC2. > Let's try our best for this. > > 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-incubatin
Re: [DISCUSS] Reorganizing the `apache/cloudberry-bootcamp` repo
Hi Leonid, Totally agree — let’s move the build scripts into the main repo. Having everything in one place will simplify development, especially for larger changes like PAX support. It’ll streamline testing, reduce cross-repo friction, and make iteration much faster. We can always revisit a split setup later if our release needs grow. Thanks for raising this — fully on board. -=e On Mon, Jun 9, 2025 at 1:47 AM Leonid Borchuk wrote: > I totally agree. It would be great to have a single library where all of > our > assets are stored. > > But until we start large-scale reconstruction work, I would like to ask a > slightly off-topic question: Why do we even need a > cloudberry-release-devops? > Why can't all our scripts be stored in the main repository? > > It happens to be rather tedious to use two repos, especially when changing > something big. Such as adding PAX support. For such a big change you need > to commit something breaking the building to the main repo. And at that > point, your tests will fail. Then you have to fix the > cloudberry-release-devops (add additional packages), but the tests may > still fail. And now you could fix the tests and make a final commit. And > only now can one check if everything is OK. We could store all our scripts > together with the code. > > Best regards, Leonid > > On Mon, Jun 9, 2025 at 9:05 AM Dianjin Wang wrote: > > > Hi all, > > > > Over the past two years, the bootcamp repo has grown to include > > various types of content, such as sandbox Dockerfiles, tutorials, and > > learning materials. I’d like to start a discussion around reorganizing > > the `apache/cloudberry-bootcamp` repo to improve clarity and > > maintainability across our community resources. > > > > The primary motivation is to consolidate content by type and reduce > > redundancy, which would: > > * Make it easier for contributors to find and update documentation > > * Reduce ongoing maintenance overhead > > > > ## Proposal (for discussion) > > > > I propose reorganizing this bootcamp repo as follows: > > > > * Move sandbox-related files to `apache/cloudberry-devops-release`, > > where we maintain tools related to deployment and release automation > > -- a new dir called `sandbox` will be created to store them. > > * For the benchmark test files -- a new directory called `benchmark` > > will be created under `apache/cloudberry-devops-release`, but we can > > do this until these files are ready. > > * Migrate tutorials, crash courses, and learning content to the > > `apache/cloudberry-site` repo, which now serves as the single source > > for end-user documentation. All of these materials have been copied to > > our website repo [1]. > > > > Once the content has been fully migrated and verified, plan to: > > > > * Archive the cloudberry-bootcamp repository, with a notice in the > > README indicating that it is no longer actively maintained and that > > the relevant content has been moved. > > > > ## Request for Feedback > > > > This is just a proposal at this stage. I’d love to hear your thoughts > > and suggestions. If most of the members agree, I would like to help > > take action on this plan. > > > > Thanks, and looking forward to your feedback! > > > > [1] https://cloudberry.apache.org/bootcamp#cloudberry-sandbox > > > > Best, > > Dianjin Wang > > > > - > > 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: [VOTE] Release Apache Cloudberry (Incubating) 2.0.0-rc1
Hi Ed, This file name appears to be a fair use to me, as it doesn't cause any confusion with branding-related items, such as product names or domain names. (This is not my area, though) Bests, Kent Ed Espino 于2025年6月9日周一 16:47写道： > Hi Kent, > > While I have you — I’d also appreciate your thoughts on a related concern > we discovered during the RC1 review. > > The source release currently includes a script named greenplum_path.sh, > which is generated by gpMgmt/bin/generate-greenplum-path.sh during > installation. These filenames contain the Greenplum trademark, which is > owned by Broadcom Inc. > > Given ASF’s guidelines around third-party trademarks (especially in > filenames and user-visible output), I’ve flagged this as a release-blocking > issue. We’re tracking it here: > https://github.com/apache/cloudberry/issues/1149 > > I’d like to get your perspective — do you agree this requires action before > final release? And if so, do you have a preference between: > >1. > >Renaming the script to something neutral like cloudberry_env.sh, or >2. > >Retaining the current name but strengthening the trademark disclaimer? > > Thanks again for raising the earlier concern and helping to shape a > stronger release. > > Best, > -=e > > > On Mon, Jun 9, 2025 at 12:37 AM Kent Yao wrote: > > > H Ed, > > > > Do you mean that ce1fc9438989ac22146c1c7e483933f3560e6572 is not the > > final hashtag if RC1 passes, and there will be new commits to replace > > 2.0.0-incubating-rc1 with 2.0.0-incubating in the source release? > > If so, the checksum verification step here becomes a variable. > > > > Kent > > > > Dianjin Wang 于2025年6月9日周一 11:12写道： > > > > > Hi Ed, > > > > > > Thanks for pointing out these issues. They helped shape a better > release. > > > > > > 1. For #1149, I admit that the filename change will have a few but not > > > a significant impact on the traditional user, especially those who > > > immigrated from Greenplum to Cloudberry. > > > > > > I'm not sure if we should add the following text to the disclaimer to > > > avoid the name change: > > > > > > ``` > > > Greenplum® is a registered trademark of Broadcom Inc. Apache > > > Cloudberry (Incubating) is not affiliated with, endorsed by, or > > > sponsored by Broadcom Inc. Any references to Greenplum are for > > > comparative, educational, and interoperability purposes only. > > > ``` > > > > > > Above is the easiest way. If not, I support the file rename for better > > > ASF compliance as soon as possible. As per your suggestion, we can > > > explicitly document these changes in our changelogs. > > > > > > Here, we may also need the input from our mentors. > > > > > > 2. For #1148, in my opinion, it's not a high-priority issue, but it > > > would improve the user experience if it could be improved before RC2. > > > Let's try our best for this. > > > > > > 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
Re: [VOTE] Release Apache Cloudberry (Incubating) 2.0.0-rc1
Hi Kent, You’re absolutely right — I’ve now confirmed that the internal version string does include -rc1. That suffix should only exist in the artifact name and Git tag, not in the version metadata of the release itself. This means RC1 is invalid from a release policy standpoint, and I’ll need to re-roll RC2 with the corrected version string (2.0.0-incubating), using a new commit and tag. Thanks again for raising this — it’s an important catch that ensures long-term integrity of the release. Best, -=e On Mon, Jun 9, 2025 at 12:37 AM Kent Yao wrote: > H Ed, > > Do you mean that ce1fc9438989ac22146c1c7e483933f3560e6572 is not the > final hashtag if RC1 passes, and there will be new commits to replace > 2.0.0-incubating-rc1 with 2.0.0-incubating in the source release? > If so, the checksum verification step here becomes a variable. > > Kent > > Dianjin Wang 于2025年6月9日周一 11:12写道： > > > Hi Ed, > > > > Thanks for pointing out these issues. They helped shape a better release. > > > > 1. For #1149, I admit that the filename change will have a few but not > > a significant impact on the traditional user, especially those who > > immigrated from Greenplum to Cloudberry. > > > > I'm not sure if we should add the following text to the disclaimer to > > avoid the name change: > > > > ``` > > Greenplum® is a registered trademark of Broadcom Inc. Apache > > Cloudberry (Incubating) is not affiliated with, endorsed by, or > > sponsored by Broadcom Inc. Any references to Greenplum are for > > comparative, educational, and interoperability purposes only. > > ``` > > > > Above is the easiest way. If not, I support the file rename for better > > ASF compliance as soon as possible. As per your suggestion, we can > > explicitly document these changes in our changelogs. > > > > Here, we may also need the input from our mentors. > > > > 2. For #1148, in my opinion, it's not a high-priority issue, but it > > would improve the user experience if it could be improved before RC2. > > Let's try our best for this. > > > > 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. A
Re: [VOTE] Release Apache Cloudberry (Incubating) 2.0.0-rc1
Hi Kent, While I have you — I’d also appreciate your thoughts on a related concern we discovered during the RC1 review. The source release currently includes a script named greenplum_path.sh, which is generated by gpMgmt/bin/generate-greenplum-path.sh during installation. These filenames contain the Greenplum trademark, which is owned by Broadcom Inc. Given ASF’s guidelines around third-party trademarks (especially in filenames and user-visible output), I’ve flagged this as a release-blocking issue. We’re tracking it here: https://github.com/apache/cloudberry/issues/1149 I’d like to get your perspective — do you agree this requires action before final release? And if so, do you have a preference between: 1. Renaming the script to something neutral like cloudberry_env.sh, or 2. Retaining the current name but strengthening the trademark disclaimer? Thanks again for raising the earlier concern and helping to shape a stronger release. Best, -=e On Mon, Jun 9, 2025 at 12:37 AM Kent Yao wrote: > H Ed, > > Do you mean that ce1fc9438989ac22146c1c7e483933f3560e6572 is not the > final hashtag if RC1 passes, and there will be new commits to replace > 2.0.0-incubating-rc1 with 2.0.0-incubating in the source release? > If so, the checksum verification step here becomes a variable. > > Kent > > Dianjin Wang 于2025年6月9日周一 11:12写道： > > > Hi Ed, > > > > Thanks for pointing out these issues. They helped shape a better release. > > > > 1. For #1149, I admit that the filename change will have a few but not > > a significant impact on the traditional user, especially those who > > immigrated from Greenplum to Cloudberry. > > > > I'm not sure if we should add the following text to the disclaimer to > > avoid the name change: > > > > ``` > > Greenplum® is a registered trademark of Broadcom Inc. Apache > > Cloudberry (Incubating) is not affiliated with, endorsed by, or > > sponsored by Broadcom Inc. Any references to Greenplum are for > > comparative, educational, and interoperability purposes only. > > ``` > > > > Above is the easiest way. If not, I support the file rename for better > > ASF compliance as soon as possible. As per your suggestion, we can > > explicitly document these changes in our changelogs. > > > > Here, we may also need the input from our mentors. > > > > 2. For #1148, in my opinion, it's not a high-priority issue, but it > > would improve the user experience if it could be improved before RC2. > > Let's try our best for this. > > > > 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
Re: [DISCUSS] Reorganizing the `apache/cloudberry-bootcamp` repo
I totally agree. It would be great to have a single library where all of our assets are stored. But until we start large-scale reconstruction work, I would like to ask a slightly off-topic question: Why do we even need a cloudberry-release-devops? Why can't all our scripts be stored in the main repository? It happens to be rather tedious to use two repos, especially when changing something big. Such as adding PAX support. For such a big change you need to commit something breaking the building to the main repo. And at that point, your tests will fail. Then you have to fix the cloudberry-release-devops (add additional packages), but the tests may still fail. And now you could fix the tests and make a final commit. And only now can one check if everything is OK. We could store all our scripts together with the code. Best regards, Leonid On Mon, Jun 9, 2025 at 9:05 AM Dianjin Wang wrote: > Hi all, > > Over the past two years, the bootcamp repo has grown to include > various types of content, such as sandbox Dockerfiles, tutorials, and > learning materials. I’d like to start a discussion around reorganizing > the `apache/cloudberry-bootcamp` repo to improve clarity and > maintainability across our community resources. > > The primary motivation is to consolidate content by type and reduce > redundancy, which would: > * Make it easier for contributors to find and update documentation > * Reduce ongoing maintenance overhead > > ## Proposal (for discussion) > > I propose reorganizing this bootcamp repo as follows: > > * Move sandbox-related files to `apache/cloudberry-devops-release`, > where we maintain tools related to deployment and release automation > -- a new dir called `sandbox` will be created to store them. > * For the benchmark test files -- a new directory called `benchmark` > will be created under `apache/cloudberry-devops-release`, but we can > do this until these files are ready. > * Migrate tutorials, crash courses, and learning content to the > `apache/cloudberry-site` repo, which now serves as the single source > for end-user documentation. All of these materials have been copied to > our website repo [1]. > > Once the content has been fully migrated and verified, plan to: > > * Archive the cloudberry-bootcamp repository, with a notice in the > README indicating that it is no longer actively maintained and that > the relevant content has been moved. > > ## Request for Feedback > > This is just a proposal at this stage. I’d love to hear your thoughts > and suggestions. If most of the members agree, I would like to help > take action on this plan. > > Thanks, and looking forward to your feedback! > > [1] https://cloudberry.apache.org/bootcamp#cloudberry-sandbox > > Best, > Dianjin Wang > > - > To unsubscribe, e-mail: dev-unsubscr...@cloudberry.apache.org > For additional commands, e-mail: dev-h...@cloudberry.apache.org > >
