首先,回報者(originator)以 send-pr(1) 送出 PR,然後會收到一封確認信。
然後,committer 們就會有人(假設叫做 Joe)發掘有興趣的 PR 並將該 PR 指派給自己來處理。 或者 bugbuster 會有人(假設叫做 Jane) 就會下決定:她覺得 Joe 比較適合處理,就將該 PR 指派(assign)給他
Joe 會先與有問題的回報者作些意見交流(以確定這問題有進入 audit 追蹤流程內) 以及判斷問題點。 然後再確定問題點有寫入 audit 追蹤流程之後,然後把該 PR 狀態設為 “analyzed(已分析)”。
Joe 開始徹夜找出問題解法,然後將 patch 送到 follow-up(回文用),並請回報者協助測試是否正常。 然後,他就會將 PR 狀態設為 “feedback” 囉。
如此重複 analyzed、feedback 幾趟之後,直到 Joe 與回報者雙方都相當滿意 patch 結果,
於是就會將 patch 給 commits 進入 -CURRENT
(或者若 -CURRENT
上面沒這問題的話,就直接送到 -STABLE
),在 commit log 內要把相關 PR 寫上去
(同時回報者若有送完整或部分 patch 的話,就順便記載),然後,若沒什麼事的話,就開始準備 MFC 哩。
(譯註:MFC意指 Merged From CURRENT ,也就是把 -CURRENT
上的東西併入 -STABLE
。
若該 patch 不需要 MFC 的話,Joe 就會關掉(close)該 PR 了。
若該 patch 需要 MFC 的話,Joe 會把 PR 狀態改為 “patched(已修正)”, 直到已經 MFC 完畢,才會 close(關掉)。
很多送出來的 PR 都很少附上問題的相關訊息,而有些則是相當複雜難搞, 或只是提到部分表面問題而已; 遇到這種情況時,是非常需要得到所有相關訊息以便解決問題。 若遇到這種無解的問題或再次發生的話,就必須要 re-open(重新開啟) 該 PR,以待解決。
PR 上所附的 “email address” 可能因某些原因而無法收信時,遇到這種狀況,通常就是 followup 該 PR ,並(在 followup 時)請回報者重新提供可正常收信的 email address。 當系統上的 mail 系統關閉或沒裝的時候,這通常是在使用 send-pr(1) 的替代方案。
All FreeBSD documents are available for download at http://ftp.FreeBSD.org/pub/FreeBSD/doc/
Questions that are not answered by the
documentation may be
sent to <freebsd-questions@FreeBSD.org>.
Send questions about this document to <freebsd-doc@FreeBSD.org>.