本文来源于 2025 年 8 月 Apache Cloudberry Meetup · 北京站，由酷克数据 HashData 根据分享整理，嘉宾在此基础上根据项目最新状态做了增删，补充了更多细节。
分享嘉宾：王殿进，Apache Cloudberry PPMC 成员、酷克数据开源负责人
感谢大家参与本次 Apache Cloudberry 社区 Meetup，在去年 8 月份我们同样在北京举办了 Cloudberry 的首场 Meetup，当时恰逢 Greenplum 项目刚刚归档并走向闭源开发，今天也碰到了很多老朋友，感谢大家对 Cloudberry 的关注和支持！
在过去近一年时间里，很多事情都发生了变化，特别是在 Greenplum 走向闭源开发后，我们联合原 Greenplum 生态伙伴和开发者一起将 Cloudberry 推动到 Apache 孵化器进行孵化，并将品牌由 Cloudberry Database 升级为 Apache Cloudberry，目前还在孵化过程中。去年我主要和大家谈了 Cloudberry 如何从一个内部项目转变为一个开源项目，同时分享了在开源过程中我们的实践；今天的主题更进一步，主要和大家汇报下 Cloudberry 在 Apache 孵化器下的合规治理实践，同时这些成果也包括在了 Apache Cloudberry 首个 Apache Release —— Apache Cloudberry 2.0.0 之中。
Apache Cloudberry 发展历史
在介绍 Apache Cloudberry 历史之前，我们先来看下 Greenplum Database 过去的发展历史和脉络。Greenplum Database 由 Greenplum Inc 团队创始于 2003 年，一开始并不是开源软件。随后，Greenplum 公司被 EMC 于 2010 年收购。在 2012 年，EMC 和 VMware 将包括 Greenplum Database 在内的软件资产进行整合，联合成立了 Pivotal Software。接着，在 2015 年，Pivotal 将 Greenplum 开源，Greenplum 也成为首个开源的 MPP 数据仓库项目，正式开启开源旅程。2019 年，VMware 收购 Pivotal Software，Greenplum 回归 VMware；2023 年，Broadcom 收购了连同 Greenplum Database 在内的 VMware，并最终在 2024 年走向闭源。总体来看，从闭源到开源，Greenplum 将近拥有 9 年多的时间处于开源状态，接着就是从开源回到闭源。
Greenplum Database 在开源数据库生态中始终扮演着重要角色。自2015年开源以来，凭借着强大的 MPP（Massively Parallel Processing）架构和分析型能力，Greenplum 在企业数据仓库和大规模计算领域拥有广泛的用户基础。Greenplum 走向闭源这一动作具有很大的标志意义，也让社区用户和行业非常震惊，当然我在和很多社区用户接触过程中发现很多原来的 Greenplum 开源用户还没察觉它已闭源——这是非常有意思的事情，处于断档风险之中而未察觉。
我们再看下 Apache Cloudberry 的发展历史。Apache Cloudberry 的发展历史相比 Greenplum 还不算太长，它于 2022 年启动、基于 Greenplum 7.0 alpha 版本演进，在一年以后也就是 2023 年 6 月在 GitHub 上开源，开源之后并没有进行大规模的市场活动，而是专注在适应开源开发协作流程、打造和完善各种基础设施之上。2024 年 Greenplum 归档并走向闭源开发，这对原有的 Greenplum 社区和项目来说不是件好事情，但却给 Cloudberry 快速发展提供了契机——很多用户和开发者希望参与到 Cloudberry 社区中来，期待将 Cloudberry 作为 Greenplum 的开源替代。
期间，我们与国内外多个重要的 Greenplum 生态企业和贡献者保持紧密沟通，探讨如何让 Cloudberry 项目避免发生 Greenplum 这一局面，那就是将 Cloudberry 托管到第三方中立组织，最终在孵化领路人、导师、原有 Greenplum 生态伙伴和开发者的一起努力下，Cloudberry 在 2024 年 10 月经过讨论且获得投票通过正式进入 Apache 孵化器！2024 年 11 月，我们将 Cloudberry 及组件代码仓库迁移到 Apache 组织下，在 2025 年 8 月份 GitHub Star 超过 1000，并且经过数月努力、多轮验证迎来首个 Apache Release——Apache Cloudberry 2.0.0。
选择 Apache 孵化器
我也发现近几年开源世界发生了一些变化、暴露出一些供应链风险，特别是类似 Greenplum 这种由单一厂商控制的开源软件：一是部分热门开源项目从开源走向闭源；二是部分开源项目许可从 OSI 批准的开源协议转向 BSL（Business Source License）类协议，对如 ElasticSearch、Redis 等，对用户场景、使用规模和商业化等行为进行限制。
整体上，我个人比较理解此类型项目背后的企业厂商在面临营收增长、开源版本与企业版本协同等多方面原因做出的这种选择，但对原有的开源用户和社区并不友好。开发者们或生态企业给到了自己的答案，类似 Linux 基金会下针对 Redis、ElasticSearch、Terraform 等都有对应的 Fork 衍生项目 Valkey、OpenSearch、OpenTofu——这也是经典开源带给开发者们的兜底支持，“如果我不认同，就自己搞”。
此类项目不是简单的代码 Fork，更多的是以中立托管为根基，重新对齐社区治理理念和协同方式，由此走出不一样的道路来。一个 Fork 或者衍生项目也可以进入中立基金会但是少数，Cloudberry 很庆幸成为 Apache 孵化器下的项目。Cloudberry 的目标就是打造一个由 Apache 托管、遵循 Apache 之道、具备可持续性的下一代开源 MPP 数据库——既对开源 Greenplum 高度兼容作为首选开源替代项目，同时也打造更多现代企业级特性。Cloudberry 加入 Apache 孵化器完全与自身路线、Apache 基金会“Sfotware for the Public Good”愿景契合。
从孵化提案到正式加入孵化器
一个项目进入 Apache 孵化器都会遵循系列流程，Cloudberry 也不例外，包括：寻找领路人（Champion）、起草孵化提案、社区讨论 & 寻找孵化导师（至少2～3名）、孵化器 PMC 投票，投票通过后搭建项目基础设施、官宣——加入流程结束。进入孵化器标志着正式开启孵化之旅，进而要学会版本发布、加强社区建设等等。当然，很多事情并不完全线性，很多可以并行开展。
下面以 Cloudberry 为例，针对加入 Apache 孵化器的关键环节和事项进一步和大家分享。
孵化提案
Apache 基金会提供了孵化模版，对格式和内容没有强制要求，但最好遵循常规。孵化提案一般包括下面关键内容：
-
Abstract & Rationale -
Background & Goals -
Initial Codebase & Dependencies -
Community Plans & Governance -
Known Risks -
Committers & Affiliations
我在一次活动中，听到某位资深孵化导师分享诀窍，大意是“当你不知道怎么写的时候，可以直接复制”。大家可以在这里查看 Cloudberry 提案文本：https://cwiki.apache.org/confluence/display/INCUBATOR/CloudberryProposal，该提案由多位社区成员共同协作完成，期间反复征求初始提交者们的反馈和建议，也得到了导师们的大力支持，经过近 30 次迭代最终定稿。
在 Cloudberry 孵化提案中，特别补充了项目背景资料，介绍 Greenplum Database 发展历史、以及为什么会有 Cloudberry Database 项目。同时，仔细梳理主仓项目、网站、组件的各种依赖情况，包括运行时依赖、编译依赖、测试依赖等，并根据各依赖许可协议分门别类、让社区成员看上去一目了然——这也是耗时最多的环节之一，大部分内容都需要从源码中找答案，分清使用情形，同时很多协议变体要与协议原本比照确保归类正确。
还有一个关键环节就是确认初始提交者。当时除了内部开发成员，更多要与原有 Greenplum 的团队与个人贡献者、重量级用户接洽，沟通愿景、听取建议——类似于销售拓客、多轮沟通、建立信任，通过多种渠道挖掘意向团队，尽最大努力争取更多同行者，很多人一拍即合，也有部分团队有意愿、但未能取得领导同意或团队优势在应用面而非数据库内核开发面遗憾未能加入。最终有来自 HashData、瀚高、Yandex 和北美多位以个人身份参与的原 Greenplum 开发者们一起作为初始提交者参与进来，过程属实不易，结果属实感激。
孵化启动
经过孵化器社区充分讨论和投票通过后，Cloudberry 正式加入 Apache 孵化器、开始孵化之旅。那么问题来了：我们像一个安装好的非图形交互的全新操作系统，在接通电源后该如何进行下一步呢？在此感谢导师们的支持，帮忙创建引导文件，为后续项目内核加载创建条件：
-
创建 Bootstrap（启动）文件：cloudberry.xml -
申请 DNS：cloudberry.apache.org -
创建 LDAP（Lightweight Directory Access Protocol） -
创建邮件列表： -
private@c.a.o：专门用于安全漏洞、提名新 Committer/PPMC 成员，其他讨论大部分在 dev 邮件列表上发生 -
dev@c.a.o：日常开发讨论，涉及社区和项目各个方面（上面提到的除外） -
commits@c.a.o：日常仓库变更日志，包括 Issue、PR、Commit 合并等，消息较多
还有更多邮件列表类型，但这三种在项目初期足够用了，特别注意 PPMC 成员必须全部订阅，如果类似 commits@ 邮件列表消息较多、堆满邮箱，可创建分类自动归档即可解决烦恼；PPMC 成员也可以与导师协调，申请成为邮件列表的 Moderator（类似“版主”），协助导师一起管理（如垃圾邮件、或解除误判的正常沟通邮件限制等）。
在孵化提案获得通过后，可请求导师加速处理这一环节任务。
PPMC 成员初始事项
作为 PPMC 成员，在孵化启动时也有很多任务要完成，除了上面提到的必须订阅全部项目邮件列表外，还有：
-
签署个人贡献者协议（简称 CLA） -
创建 Apache Id ，设置 Apache 账号 -
加入 Apache Cloudberry PPMC 团队 -
配置 gitbox.apache.org，方便你拥有 GitHub 项目仓库写入权限
可以将全部初始提交者信息统一整理到协作文档或表格中，方便跟踪完成情况，包括提交者个人信息（如姓名、个人邮箱、GitHub Id、所在公司、Apache ID、Apache 邮箱）、CLA 签署、是否加入 PPMC 团队、是否订阅邮件列表等。
我们在这里参考了大量成熟项目公开文档，针对自身项目总结成公开文档，方便 PPMC 成员完成任务时参考，如：
-
个人贡献者协议签署： -
说明如何下载、进行电子签名，各字段如何填写有什么坑要避开，发送给谁、发送邮件模版等，一步一步列出来，让大家照着样子做，但即使如此也会有各种问题产生，请不要高估每个人阅读文档的耐心 -
字段填写。如 Full Name 字段，要填写全名称；Public Name，可以复用 Full Name 或输入新名称，如不输入，默认使用 Full Name；Postal Address，一定要填写居住地址并具体到门牌号、x 楼 x 室，不要个人所在团队办公地址否则大概率会被拒掉；Email：输入常用个人邮箱，推荐此处填写及后续绑定 Gmail 邮箱，体验较好；Apache id：就是用在你的 @apache.org 邮箱前面的名字，也是你的 Apache 账号 ID；notify project，填写当前孵化项目即可 -
如何电子签名：分清 macOS、Android、iOS 系统上怎么处理，不用使用物理打印机也可以做到 -
Cloudberry 社区公开文档：https://cloudberry.apache.org/team/sign-icla ， -
加入 Apache Cloudberry PPMC 团队：需要导师协助将初始提交者们加入，一旦加入后，你也可以通过相关入口将其他后续 PPMC 成员添加进来，不要全部丢给导师来处理，处理地址可通过 https://whimsy.apache.org/roster/ppmc/$project 地址查看 -
配置 Apache 账号：很多人疑惑如何配置 Apache 邮箱来收发邮件，可参考 Cloudberry 社区文档 https://cloudberry.apache.org/team/setup-apache-email-account
同时，项目捐赠主体也要完成 SGA（Software Grant Agreement） 签署，送交 Apache 秘书处备案。
品牌与命名
在品牌有关规则更改之前，在加入孵化器后，推荐尽快提交项目名称搜索工单（Podling Name Search Jira ticket），请求 ASF 品牌管理委员会主席批准通过；提交工单时，可参考其他项目模版，尽量确保搜索情况全面，为批准提供足够参考依据。如果不通过，需要尽早更名，避免毕业时更名带来更多负担。项目名称获得通过后，推荐在项目官网、Logo 等露出时添加商标字符™️。
同时，在官网及对外使用项目名称时，尽量带有 Incubating 字样，如 Cloudberry 项目名称标准写法为：Apache Cloudberry ™️ (Incubating)，但也不是处处都要求使用全称，在首页标题、开头最显眼处使用即可，后面下文可使用类似 Apache Cloudberry 或 Cloudberry 指代，具体规范请阅读 Apache 品牌规则。
如果在项目进入孵化器之前已有正在使用的标志，在加入孵化器后如有必要请更新，视情况判断，如名称等发生变化；项目标志，可上传 https://apache.org/logos/，方便后续加载引用；鼓励为社区提供多种标志变体，方便在社交媒体传播、活动推广、网站设计等场景选择使用，如横版、竖版、纯文字标志、纯图形标志、文字+图形标志、彩色与黑/白等组合样式，建议提供 PNG、SVG 格式，以及基于 Apache 孵化器标志制作圆环标志，可参考 Cloudberry 品牌指南 https://cloudberry.apache.org/community/brand。
原有的社交媒体账号确保命名更新到最新，类似 Twitter、LinkedIn 账号 ID 可采用 @ASF$project 或 @Apache$project格式，显示名称使用带有 Incubating 的全称。
代码仓库迁移
在 Apache Infra 团队 Jira 系统创建代码仓库迁移到 Apache GitHub 组织的工单，获得回应后，可在原仓库/原组织将对应 Apache Infra 团队成员添加 Admin 权限，便于其协助进行仓库迁移，确认仓库迁移完成后解除其权限。
仓库迁移完成后，我们将无法继续通过 GitHub Web 界面设置仓库，需要引入 .asf.yaml 文件来对仓库的描述、标签、功能启用、分支保护、通知策略等做配置，可参考文档：https://github.com/apache/infrastructure-asfyaml/blob/main/README.md。
仓库迁移完成后，也需要检查原有 CICD 工作流是否能继续正常工作，否则要重新适配，尽快恢复正常开发节奏。
代码清理
代码清理对已有很长开发历史的项目来说是一项艰巨的工作。首先，如果项目名称发生变化，建议更新代码仓库中存在的旧有名称（包括注释、与最新项目名称不匹配的简称），将其升级为最新名称，强化品牌统一性。同时，在新引入的代码中不鼓励继续使用旧有名称。
此外，也需要重新审视项目源码文件，看看哪些组件、配置已经不再使用、废弃了，就大胆的将他们删掉吧。由于 Cloudberry 衍生自 Greenplum，源码中仍保留原 Greenplum 使用的旧有 Concourse CI 系统配置文件，很明显 Cloudberry 转向 GitHub Actions 搭建了全新的 CICD 工作流，所以我们移除了原有 Concourse 关联文件；同时，原在内部使用的 CI 特定配置文件也一并删除等等。
过往很多为同一功能存在的文件分散在各处，我们也将他们统一归类。一通操作下来，代码仓库干净、整齐了很多，这就相当于“打扫干净屋子再请客”。
Apache 许可合规
此处比较关键的是如何针对源码文件应用 Apache 许可文件头。由项目社区原创的文件，务必添加标准的 Apache 许可文件头；引入的第三方项目源码文件（确保与 Apache 协议兼容），即使有调整，也不改动源文件头、维持原样（即使有标点、错别字等明显错误），如果对原文件有超级大改动，可单独讨论。当然，由于 Cloudberry 和 PostgreSQL 有超强的代码血缘，我们在原标准 Apache 许可文件头内容的尾部追加了一些可选设置，使之更加符合 PostgreSQL 开发风格。类似原创的 Markdown、YAML 等文件，鼓励添加标准 Apache 许可文件头，避免在 Release 审核时被指出（备注：目前看该类型文件评价不一致，添加上总没错）。
同时，要分辨出哪些是项目原创文件，哪些是引入的其他开源项目文件，尽量一一追本溯源。如果项目加入孵化器前就有很长的开发历史，这块花费时间会比较长。因为在历史开发过程中，很多开发者或团队对此没有特别的意识和处理规范，大家的目标还是聚焦在完成功能交付。
如果引入了与 Apache 许可不兼容的许可文件或组件，我们需要移除或者寻找其他兼容性替代。如在 Cloudberry 中，我们使用遵循 MIT 许可的 ruff 替代遵循 GPL3 的 Pylint 来处理 Python 代码分析和格式化需求。针对依赖的组件，我们放弃直接搭载其源码压缩包的方式，改为在安装过程中启动下载；二进制文件也需要清理。
针对许可协议合规检查，我们采用了 Apache RAT 工具，该工具支持为 Apache 项目发布版本提供文件许可协议审核。通过 pom.xml 定义验证规则后，可通过命令 mvn apache-rat:check 获取验证结果。同时，为了避免在 Release 时积累大量审核任务，我们上线了 Apache RAT 审核工作流（设为强制），可对日常开发 Pull Request 进行检查，及早发现非合规性文件引入，该工作流运行成功后才能合并到主分支。
LICENSE、NOTICE 和 DISCLAIMER 是孵化项目必须处理好的三个文件，可参考基金会提供的指南来仔细操作。LICENSE 是许可协议文件，需要将 Apache 标准许可本文放置在该文件中；如果有引入的其他许可协议文件，可将它们附在后面一一列出，标注好对应文件位置、所属协议名称及其协议文本，建议将不同协议分类，同一协议的放置在一起，更加直观；如果此类情况较多，建议将对应的协议文本单独存放在类似 licenses 目录中，方便管理，避免 LICENSE 文件过长。
DISCALIMER 在孵化项目源码中必须具备，表明该项目仍处孵化之中、尚未完全被 Apache 基金会完全认可接受，做到提醒义务。NOTICE 文件也可以按指南撰写，非必要不要过多加入声明，避免给下游带来额外压力。
目前 Apache Cloudberry 2.0.0 版本已发布，在即将到来的 2.1.0 中，我们将会升级原来的环境变量 greenplum_path.sh 到 cloudberry-env.sh，你可以在此查看社区讨论：https://lists.apache.org/thread/b8o974mnnqk6zpy86dgll2pgqcvqgnwm 以及社区博文 https://cloudberry.apache.org/blog/from-greenplum-path.sh-to-cloudberry-env.sh，目标主要是强化 Apache Cloudberry 独立品牌，同时避免在用户直接接触面使用由博通拥有的 Greenplum 注册商标、规避侵权风险。对于此改变，我们分两步走：
-
阶段 1：在 2.0.0 保持非破坏性，仅在用户运行 source greenplum_path.sh查看变更通告，其他无影响 -
阶段 2：在后续 2.1.0 版本中应用变更，将 greenplum_path.sh 全面升级为 cloudberry-env.sh
Apache Release
Apache release 和我们过往认知的 release 存在区别：对于 Apache release 来说，只认可源码，便于每个人可以通过源码从头构建、并且根据需要修改源码；我们过往认知的版本软件包如 .rpm、.deb 等均属于便携二进制包（Convenience binary），Apache 允许社区提供此等格式软件包方便用户安装使用，但必须基于已发布的 release 源码进行制作。
Apache 孵化项目版本发布，要经过两阶段投票：第一轮由孵化项目社区展开，至少获得 3 名 PPMC 成员投票；第一轮投票成功后，进入第二轮 Apache 孵化器社区投票，此轮投票必须获得至少 3 名 Apache 孵化器社区 PMC 成员约束性投票（binding）。只有第二轮投票正式通过后，Apache 孵化项目才被允许发布正式版本。Release 作为 Apache 孵化项目必修关键科目之一，两阶段投票第一阶段就是为了让 Apache 孵化项目社区自身熟悉 Release 流程，第二阶段应该就是获得更多有成熟经验的孵化导师给予反馈、做好把关。
我们在之前提到过，一个孵化项目最好有至少 2～3 名导师，在项目 Release 的时候作用就出现了。相信并不是所有孵化器 PMC 成员熟悉你所在项目、或者能腾出时间给予反馈。为了避免无人投票无法推进版本发布，建议联络项目导师率先响应。再者，你可以透过个人人脉找熟人帮忙给与反馈，针对特别复杂的项目，我理解一般人还是会跟随导师，大家不会随便给 +1 放水。
Apache release 除了经过两阶段投票流程，还必须在源码压缩文件名称中带有 incubating 字样，提供 KEYS 文件，提供分离签名文件（.asc）和校验和文件（.sha512），可参考相关指南来操作；release 最新版本通过类似 https://downloads.apache.org/incubator/cloudberry 地址分发。
在进行版本发布投票的时候，需要准备好一个清晰的检查清单及操作说明，方便项目社区和孵化器社区成员针对性核查，下面是目前 Cloudberry 社区的简明检查清单示例：
• [ ] 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 and legacy
files)
• [ ] Build completes successfully from source with clear instructions
构建社区
路线图公开讨论。在 Cloudberry 加入孵化器后，我们开展了项目路线图讨论工作，以此激发社区成员活力、凝聚社区共识，我们收集了诸多原资深 Greenplum 技术专家、开发者的宝贵建议和需求，大家具备多年 Greenplum 一线开发和生产经验，对于 Greenplum 优缺点非常熟悉，所以路线图中的方向和建议具有非常大的价值，不是凭空而来。
提名活跃贡献者成为 Committer。针对持续活跃的贡献者，无论是代码层面还是非代码层面的贡献，我们都给予认可。目前 Cloudberry 社区已经新增 3 名新 Committer，期待后续越来越多的活跃贡献者成长为 Committer。
除了上面提到的两个举措，我们还鼓励社区成员积极参加 PostgreSQL、大数据、开源等方向的大会、活动，为更多人们介绍 Apache Cloudberry；同时，也积极挖掘 Cloudberry 应用团队，与他们保持沟通交流，鼓励参与社区。
提名社区成员成为 Committer，可基于 Apache 给出的推荐模版和流程，来制定符合自身项目的模版、流程规则，如 https://cloudberry.apache.org/team/new-committers。
Apache 成熟度模型
Apache 成熟度模型为评估一个 Apache 项目社区提供了参考框架，最新版本包括 8 个方面：
• Code {CD10,...,CD50}
• Licenses and Copyright {LC10,...,LC50}
• Releases {RE10,...,RE50}
• Quality {QU10,...,QU50}
• Community {CO10,...,CO70}
• Consensus Building {CS10,...,CS50}
• Independence {IN10,IN20}
• Trademark and Branding {TB10,...,TB40}
可在此查看详情：https://community.apache.org/apache-way/apache-project-maturity-model.html。建议定期进行对照自评（可季度、年度），查看自身项目还有哪些短板弱点待增强。从孵化器孵化成功毕业成为一个顶级项目固然是每个孵化项目的最佳结局，但不能为了毕业而揠苗助长。我们相信这是一个自然成长、自然收获的过程，保持努力，等待美好自然发生。
心得与感悟
自从推动 Cloudberry 加入孵化器到现在，个人和项目都得到了很大的成长。从我个人来说，分享下在此短暂的孵化期间获得的几点重要感悟：
-
保持耐心。我们每个社区成员都要学会异步沟通方式，适应这种协作交互方式。我们的协作对象已经超出当年的内部团队和办公室，他们分布在欧洲、北美，不能强迫每个人立马做出响应。你需要为后续动作腾出更多缓冲时间，耐心等待大家响应并给出反馈。但也不能在对方持续没有响应的情况下一味保持等待，这种情况下我们要行动，不是所有的倡议、讨论都能在合理期限等到回应，遵循“懒惰共识”就好。 -
仔细阅读孵化指南文档。孵化指南里会有各种引用资料和链接，多不胜数，我们要多读孵化文档和基金会官网文档，很多问题和解决办法都能从上面得到指引。实在不知道怎么办的，请积极向导师寻求帮助，导师们在这方面踩过坑。 -
向其他孵化项目和成熟项目学习。很多孵化和成熟项目都有公开文档，针对常见的社区操作都有介绍。当你不知道怎么做的时候，多看几个项目的实践，心里就有数多了。
部分有用链接
-
孵化器网站： -
https://incubator.apache.org/ -
孵化模版：https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal -
适用于 committers/PPMC 成员 -
https://gitbox.apache.org/ -
http://id.apache.org/ -
https://whimsy.apache.org/roster/ppmc/ -
https://selfserve.apache.org/ -
孵化状态： -
网站检查：https://whimsy.apache.org/pods/ -
Clutch status：https://incubator.apache.org/clutch/ -
https://incubator.apache.org/clutch/$project.html（自动更新） -
https://incubator.apache.org/projects/$project.html（手动更新） -
仓库配置： -
.asf.yaml：https://github.com/apache/infrastructure-asfyaml/blob/main/README.md
以上是个人近期体会，限于篇幅不能展开更多细节，相信随着 Apache Cloudberry 在孵化之路上不断走深，会有更多收获，再次感谢导师、孵化器社区和 Cloudberry 社区成员们的一起努力！上文如有不妥之处，欢迎指出反馈。
推荐阅读
👇🏻️扫码加入 Apache Cloudberry 交流群👇🏻️
