ROSE 编译器框架/源代码仓库
为什么我们要考虑这个？
- ROSE 的单个单片式 git 仓库变得太大
- 如果人们只关心其中一部分，克隆大型仓库没有生产力
- 我们有许多使用 ROSE 的协作项目。许多项目贡献者被迫为提交采用与核心 ROSE 贡献者相同的标准。
- Jenkins 对不同平台、不同版本的 GCC、boost 等执行相同的严格回归测试。这对于某些项目并不总是必要的。
- 我们在 ROSE 的 git 仓库中有一些 LaTeX 文档和 HTML 网页。它们本质上可以独立存在。但是，即使对它们进行微小的错别字修复也需要进行长时间的 Jenkins 测试（大约 10 小时或更长时间）才能生效。这真的降低了我们添加/更新文档的兴趣。
为 ROSE 项目提供精益、干净且组织良好的源代码仓库
- 精益（<=100 MB）：只有必要的东西应该存储在中心核心仓库中
- 干净：只有代码审查和测试过的内容才能添加到中心仓库中
- 组织良好：直观的、标准化的目录布局
促进协作
- 允许协作、实验项目具有增量/替代测试要求
其他要求：大部分已经通过使用 git 解决
- 安全
- 备份
- 找出其他大型项目如何管理多个仓库？
- 删除不必要的 大文件：从仓库和历史记录中删除
- 将单个仓库拆分为更小的仓库。
- 允许用户只下载/克隆他们关心的内容。
- 确保它们在需要时协同工作并作为一个整体进行测试
- 准备示例仓库，演示不同类型的仓库应该如何使用
最大的问题是，通过拥有多个仓库，
- 很难确保非核心仓库始终与核心 ROSE 仓库协同工作
- 或者，对核心仓库的更改可能会在未被注意到的情况下破坏其他仓库
- 确保项目和 librose.so 版本之间的准确链接
如何防止这些问题？
- 对 ROSE 核心仓库的提交将触发对所有官方项目的测试。只有通过所有项目测试的提交才会被接受到核心仓库中。
- 类似地，对任何官方项目的更改都会触发针对最新 ROSE 的测试。只有通过所有 ROSE 测试的提交才会被接受到各个项目中
- 更好的 librose.so 版本控制：非官方（外部）项目可以轻松检测 librose.so 版本是否兼容。
对于 80% 的 ROSE 用户来说绝对必要的东西应该放在 ROSE 的核心仓库中。
它应该只包含
- 用于构建 librose.so 的源文件和头文件
- 用户开箱即用的内置工具
- Doxygen 文档
子模块
- 核心测试
问题
- 一些必要的文件怎么样：例如安装指南
- 以及与 ROSE 中某些功能紧密耦合的一些测试？
为什么我们要将一些文档从 ROSE 仓库中分离出来？
- 现在，对 ROSE 中的文档的任何更改（即使是修复错别字）都需要 Jenkins 进行相同的严格回归测试。这是不必要的，也是浪费的。
我们可能有两种选择
- 为所有项目创建一个单片式仓库。
- 允许每个项目使用单独的仓库。这样人们就可以只克隆他们想要的内容。每个项目都可以有自己的生命周期（放弃、合并到 rose 中、永远分离等）。
我认为从长远来看，大多数项目应该被视为
- 插件（或增量库） of ROSE (librose.so)。
- 与 ROSE 的内置工具相比，它是额外的工具
它们很重要且有用，但由于各种原因，它们没有合并到 ROSE 的核心。
目前的思路
- 各个项目应该是单独的仓库，可配置的 "--with-rose=/path/to/rose/installation" 用于建立 ROSE 与项目之间的连接。
- 所有官方项目的集合应该包含在一个单片式仓库中（例如“rose-projects”），其中每个项目只是一个子模块
待讨论
- 我们可以允许用户贡献只使用简单 Makefile 的项目。工作人员或付费实习生可以负责将构建系统转换为使用 autotools。
常用的测试输入文件，用于测试 ROSE 核心的健壮性的基准测试。
项目也可以利用同一套测试。