Repository Handling¶
Project Renames¶
如果您将项目重命名以移出“openstack”命名空间到任何其他命名空间，请遵循 此 OpenStack TC 决议。
对于添加到现有官方 OpenStack 项目的项目：创建一个 openstack/governance 变更，并在您在以下步骤中进行的变更的提交消息中添加一个“Depends-On: project-change-url”，并在 openstack/project-config 变更中添加一个引用治理变更的注释。您还需要确保 PTL 已经以某种方式表达了对添加的批准。
如果您重命名现有的官方 OpenStack 项目，请将 openstack/governance 变更作为对 openstack/project-config 变更的依赖项，以便在重命名完成后可以合并。
不要忘记更新 Zuul 作业定义。这对于保持 Zuul 作业定义的正确性以及更好地利用 CI/CD 基础设施资源非常重要。您需要查找退休仓库是否在 master 和 stable 分支的 Zuul 作业定义中作为 required-projects 或任何其他地方使用。通过 codesearch 在 master 作业中搜索很容易，但在 stable 分支中搜索比较棘手。确保清理所有 stable 分支，包括处于 Extended Maintenance 状态的分支。否则会导致 Zuul 配置错误，这些错误可以在 Zuul 配置错误列表 中找到
重命名项目的详细步骤记录在 OpenDev 手册的 Project Renames 部分。
Retiring a Repository¶
如果您需要退休一个项目并且不再接受补丁 - 对于 master 和 stable 分支 -，重要的是同时通知用户和贡献者。以下步骤将帮助您优雅地结束一个项目。
注意
以下部分实际上是单独的步骤。如果您的项目设置了作业，您需要按照以下说明和 OpenDev 手册提交 *四个* 不同的变更。我们建议使用“Depends-On:” 和 “Needed-By:” 标头链接这些变更。
Step 1: End Project Gating¶
遵循 OpenDev 手册中的 End Project Gating 关于步骤 1。
注意
请保留 official-openstack-repo-jobs 模板，以同步退休到 GitHub 镜像。
Step 2: Remove Project Content¶
遵循 OpenDev 手册中的 Remove Project Content 关于步骤 2。
Step 3: Retire Repository from the Governance Repository¶
此步骤是通过从 reference/projects.yaml 文件中退休仓库并将其添加到 reference/legacy.yaml 文件中，在技术委员会获得同意。请注意，如果该项目最近处于活动状态，这可能会对 ATC 的自动检测产生影响。
我们需要等待此补丁首先合并，然后再继续。这里的关键目标是获得技术委员会的同意，并使用治理脚本来检查正确的退休，这将帮助我们避免任何重新退休的工作。
注意：在步骤 2 中提交的 Remove Project Content 补丁上使用 Depends-On。
Step 4: Stop requirements syncing (if set up)¶
提交对 openstack/requirements 项目的审查，从 projects.txt 中删除该项目。这同样需要发生在 stable 分支上。
注意：在步骤 3 中提交的 governance 补丁上使用 Depends-On。
Step 5: Remove repository references¶
确保已正确删除对退休仓库的所有引用。需要审计和更新的几个地方是
检查所有项目的源代码和文档，看看是否有对退休仓库的任何引用。使用 codesearch 进行检查。
Zuul job definitions
这对于保持 Zuul 作业定义的正确性以及更好地利用 CI/CD 基础设施资源非常重要。您需要查找退休仓库是否在 master 和 stable 分支的 Zuul 作业定义中作为
required-projects或任何其他地方使用。通过 codesearch 在 master 作业中搜索很容易，但在 stable 分支中搜索比较棘手。确保清理所有 stable 分支，包括处于Extended Maintenance状态的分支。否则会导致 Zuul 配置错误，这些错误可以在 Zuul 配置错误列表 中找到
注意：在步骤 3 中提交的 governance 补丁上使用 Depends-On。
Steps 6: Remove Project from Infrastructure Systems¶
遵循 OpenDev 手册中的 Remove Project from Infrastructure System 关于步骤 3，但使用 /home/gerrit2/acls/openstack/retired.config 而不是那里提到的 ACL 文件，以便技术委员会将来仍然可以对内容进行调整。
注意：在步骤 3 中提交的 governance 补丁上使用 Depends-On。
Step 7: Remove docs.openstack.org content¶
通知访问您的仓库的 docs.openstack.org 页面的用户，该页面已退休。
为此，将您的仓库名称添加到 tools/www-generator.py 文件中的 _RETIRED_REPOS 列表中，该文件位于 openstack/openstack-manuals 仓库中。一旦变更合并，URL https://docs.openstack.org/openstack/<projectname>/latest 将重定向到仓库的 README.rst 文件。
注意：在步骤 3 中提交的 governance 补丁上使用 Depends-On。
Step 8: Retire deliverables in releases repository¶
鉴于该项目正在退休，将不再有任何发布。因此，您必须在 openstack/releases 仓库中执行两项任务。
首先，完全删除当前开发周期目录中的交付物的 yaml 文件。例如，如果您的交付物是 puppet-panko，而当前的开发周期是 Ussuri，则必须删除 deliverables/2025.2/puppet-panko.yaml。
接下来，如果您的交付物具有受支持或未维护的 stable 分支，例如 stable/train，则必须使用该 stable 分支上存在的最新哈希值将其 EOL。
---
- version: xena-eol
projects:
- repo: openstack/magnum
hash: c5f8c78ef3ad93c830b5dc49ab6053252333b077
...
注意：在步骤 3 中提交的 governance 补丁上使用 Depends-On。
Step 9: Update openstack-map to remove the retired project¶
如果退休的仓库/项目列在 openstack-map 中，您需要将其从那里删除。
例如：https://review.opendev.org/c/openinfra/openstack-map/+/764544
在步骤 1 中提交的 governance 补丁上使用 Depends-On。
Deprecating a Repository¶
如果您只想停止 master 分支的开发，但保留 stable 分支，您需要采取略有不同的方法。
弃用项目或仓库与删除不同。如果项目希望停止 master 分支的开发，但支持 stable 分支的 bug 修复，则必须将项目标记为已弃用。如果项目没有 stable 分支，则可以选择直接进行删除过程。
Step 1: Mark the Repository as Deprecated in the Governance Repository¶
在 openstack/governance 仓库的 reference/projects.yaml 文件中将仓库标记为已弃用，并添加一行
deprecated: <deprecated-cycle-name>
release-management: deprecated
Step 2: Stop requirements syncing (if set up)¶
提交对 openstack/requirements 项目的审查，从 projects.txt 中删除该项目。
注意：在步骤 1 中提交的 governance 补丁上使用 Depends-On。
Step 3: Stop deliverables from the current development branch¶
我们将要退休项目的 master 分支，并且不会从该分支进行任何发布。假设当前的开发周期是 2999.2，发布别名是“Xylophone”。提交对 openstack/releases 仓库的审查，从 deliverables/xylophone/ 目录中删除交付物的 yaml 文件。
最近的一个例子是，gerrit 审查在 Caracal 开发周期期间弃用了 cinderlib 的交付物：https://review.opendev.org/c/openstack/releases/+/904862
注意：在步骤 1 中提交的 governance 补丁上使用 Depends-On。
Step 4: Retire master branch¶
如果仓库是无分支的（例如，Tempest 及其插件），并且其 master 分支内容需要支持其他交付物的 stable 分支直到它们退休或达到 EOL，那么您可以跳过此步骤 3，并仅更新 README.rst 文件以反映弃用说明。
Step 4a: Use only noop jobs¶
将 noop-jobs 模板添加到 project-config 仓库中的 zuul.d/projects.yaml 中，仅用于 master 分支，并暂时删除所有其他模板，但 official-openstack-repo-jobs 和 pypi 发布模板除外。如果您的项目有 publish-to-pypi 模板，则将其更改为 publish-to-pypi-stable-only。它应该如下所示
- project:
name: openstack/<projectname>
templates:
- official-openstack-repo-jobs
- publish-to-pypi-stable-only
- noop-jobs
调整项目描述。在 gerrit/projects.yaml 中找到您的项目的条目，并查找定义描述的行，在其前面加上 DEPRECATED,，如下所示
description: DEPRECATED, existing project description
Step 4b: Remove project content¶
遵循 OpenDev 手册中的 Removing project content 关于步骤 2。
Step 4c: Remove noop jobs¶
一旦项目内容退休，部分撤销您之前在步骤 3a 中合并的 project-config 的更改，并重新添加您需要的模板和作业，以便您可以合并 stable 分支上的内容。请确保保留您在步骤 3a 中添加到项目描述中的 DEPRECATED, 前缀。
注意：在所有补丁中，在步骤 1 中提交的 governance 补丁上使用 Depends-On。
Step 5: Remove docs.openstack.org content¶
通知访问您的仓库的 docs.openstack.org 页面的用户，该页面已弃用。
为此，将您的仓库名称添加到 tools/www-generator.py 文件中的 _RETIRED_REPOS 列表中，该文件位于 openstack/openstack-manuals 仓库中。一旦变更合并，URL https://docs.openstack.org/openstack/<projectname>/latest 将重定向到仓库的 README.rst 文件。
此外，如果存在，请从 openstack/openstack-manuals 仓库中的 www/project-data/latest.yaml 中的列表中删除该项目。这将从新发布列表中删除该项目。
注意：在步骤 1 中提交的 governance 补丁上使用 Depends-On。
