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 核心的健壯性的基準測試。
專案也可以利用同一套測試。