Hi Ed, Thanks for bringing this up — I’d like to contribute some context and suggestions as follows.
Best, Dianjin Wang On Fri, Apr 25, 2025 at 5:32 AM Ed Espino <esp...@apache.org> wrote: > > - Is the `deploy/` directory still in active use or maintained? Files in `deploy/build/` were originally scattered under the top-level dir in Greenplum to guide users in building the project. We moved them here for better organization. These scripts and files are used to help users build Cloudberry on Linux and macOS. However, they do need updates — including bash compatibility, dependency management, and OS support. We might cherry-pick updates from Greenplum or revise them ourselves. The `vagrant/` directory, previously under `src/tools/vagrant/` in Greenplum, was also moved here. However, these files have not been maintained upstream for over 5–6 years and use VirtualBox as the provider, which has poor support for Apple silicon in my previous testing (I'm not sure how it goes now). > - Was it contributed primarily to support internal workflows, or is it > intended to serve as a general deployment guide for the community? Files under `k8s/`, `docker/`, `script/`, as well as `cbdb_deploy.sh` and `cbdb_env.sh`, were initially to support internal workflows. As you can see, some internal URLs referenced in the files are not usable by the general public. To my knowledge, these are also not used in the public Cloudberry workflows. > - If it isn’t currently usable without access to internal resources, should > we clarify that in the README or revisit how it’s presented? For legacy and unused files, I propose we remove them entirely: - `docker/` - `k8s/` - `script` - `vagrant` - `cbdb_deploy.sh` - `cbdb_env.sh` > - Would it be valuable to provide a community-accessible deployment path > using standard open tools (e.g., Docker Compose, Helm charts, Terraform)? +1. Starting with Docker Compose would be a great first step. It could help both new users and contributors get started more easily. > - Does the current setup align with ASF expectations around transparency > and community-driven development? As suggested above, once we clean up the internal and deprecated files, it should be more aligned with ASF’s expectations. > While it’s entirely understandable that early artifacts might reflect their > original environment, continued reliance on internal infrastructure could > make onboarding harder for external users — and may not reflect the Apache > spirit of openness and independence. Agree, I acknowledged with the vendor engineers that these files are not used anymore in their internal workflows. So we can clean up these files for better openness and public access. ～～～ BTW, I started a GitHub Discussion on cleanup of `deploy` dir[1] back in Feb, but we can continue the deep discussion on this mailing thread to gather more feedback and suggestions. [1] https://github.com/apache/cloudberry/discussions/948 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cloudberry.apache.org For additional commands, e-mail: dev-h...@cloudberry.apache.org
