本文件現已廢棄。如要取得最新資訊，請參閱Apache 專案指南。


Apache 投票規則和指南

本文件定義了 Apache 小組成員投票修補程式、文件說明或其他適用於 Apache HTTP Server 的行動項目時，必須遵循的規則和指南。

此處的目標是避免不必要的衝突，並繼續及時產生優質的系統。無法避免所有衝突，但我們至少可以同意解決衝突的程序。

以下使用的一些縮寫...

郵件清單
Apache 開發人員的郵件清單。僅限邀請訂閱清單，只有訂閱者才能直接發布到清單上。
CURRENT
原始碼的最新版本。用作要合併新修補程式的基礎程式碼。
C_VERSION
CURRENT 的版本號。
NEXT
原始碼的下一版本。將已核准的修補程式套用到 CURRENT 的結果。

o 議題和行動項目

專案將會遇到許多議題，每個議題都會產生零個或多個建議的行動項目。所有行動項目都可以投票，但並非所有行動項目都需要正式投票。一經確認，應盡快在郵件清單上提出議題。必須在郵件清單上提出行動項目。

行動項目的類型

程式碼變更
程式碼變更需要在廣泛的伺服器平台上進行同儕審查和測試。因此，所有程式碼變更都必須通過正式的「修補程式投票」，如下所述說明。所有參與修補程式投票的人員都必須有能力並願意測試已修補的系統。
文件說明變更
文件說明變更只能在變更之後 (或期間) 投票。變更的作者必須通知郵件清單，最好在工作之前先通知，以避免重複工作，說明變更的位置。如果變更為現有文件，則在通知清單後至少 24 小時內不應更換現有文件。任何小組成員都可以否決變更，但必須在問題可以修正的情況下，提供作者真正的協助來修正問題，並且必須在問題修正後撤銷否決 (可以用善意假設)。
長期計畫
長期計畫僅表示小組成員正在處理與 Apache 軟體相關的特定問題的公告。這些計畫並未投票，但不認同特定計畫或認為其他計畫會更好的小組成員有義務向小組表達他們的意見。一般而言，在花時間處理較不充分的解決方案之前了解其他計畫總是比較好。

o 投票

郵件清單上的任何人均可對任何議題進行投票。不過，投票行為負有特定的義務 -- 投票成員不僅陳述他們的意見，還同意協助執行 Apache 計畫的工作。

每一票皆可用三種方式表達

+1
贊成、同意，或應執行該動作。在某些議題上，此投票僅能在投票者在其自身系統上測試動作後才能提交。

±0
棄權、無意見，或我願意讓其他小組成員決定此議題。如果太多人棄權，可能會造成不良影響。

-1
否，我否決此動作。所有否決票都必須包含否決適當的理由說明。沒有理由說明的否決票無效。

所有投票都必須寄送至郵件清單。

o 正式補丁投票

如上所述，原始程式碼的變更需要進行同儕審查和跨多個平台的充分測試。正式補丁投票規則旨在確保在我們都急著看到問題獲得解決時也能確實執行這些動作。不過，也請參閱懶惰投票模式部分。

在補丁投票流程中有四個不同的角色，每一個皆可由多位小組成員共享：補丁提供者、投票協調員、投票者和版本建置者。

補丁提供者包括任何具有建議事項的人。除非不可行，否則必須以 patch 命令輸入的方式來建議原始程式碼變更。可行性由每個投票者和版本建置者定義，如果該動作所需的努力超出他們的預期，他們可以否決該事項。

上傳事項

動作事項（通常為補丁）會透過 FTP 上傳至 hyperreal（apache.org），直接上傳至CURRENT 的補丁目錄（/httpd/patches/for_Apache_C_VERSION/），或上傳至即將轉移至補丁目錄的收件 FTP 目錄。

每個檔名至少應暗示動作目標，並包含以下資訊

  1. (C_VERSION) CURRENT 的版本號碼
  2. (ID) 獨特的動作事項數位 ID
  3. (p) 如果建議使用替代補丁檔，則為補丁字母

不包含補丁的檔名的語法為

    ID.description
例如，
    01.Modula3_rewrite
如果動作事項（仍）未以補丁形式呈現。

包含補丁的檔名的語法為

    IDp.description.C_VERSION.patch
例如，
    01.ScriptAliasKaboom.0.8.11.patch
    01a.ScriptAliasKaboom.0.8.11.patch
    01b.ScriptAliasKaboom.0.8.11.patch

ID 編號應從 01 起始，且針對每個上傳的新動作事項遞增。

事項格式

動作事項應包含一串標頭資訊（格式類似電子郵件或 HTTP 標頭）

來自
補丁作者和/或找出問題的人員清單。
主旨
針對所解決問題的說明。
需要
必須在修補程式套用前，套用其他修補程式的清單。
受影響
這個修補程式影響的原始檔名清單
變更日誌
未來變更日誌會用到的幾行文字，這樣（如果接受）修補程式就可以記錄下來。
註解
關於問題的任何其他註解。
後面接著空行，然後是修補程式（如果有）。

修補程式格式

修補程式應該是使用 **CURRENT** 來源和修改過來源的 diff -u 來建立的。例如，

    diff -u http_main.c.orig http_main.c

所有必要用來進行動作項目管理的修補程式都必須合併在單一修補程式檔案中。修補程式檔案影響的原始檔應列在受影響的標題中。

完成的修補程式檔案在發行命令，

    patch -s < patchfile
時不應產生任何錯誤或提示。

如果修補程式產生錯誤或提示，那麼其他人可能會拒絕它。一發現修補程式有任何問題，就應向郵件清單回報。修補程式之間的相依性必須在修補程式檔案標題中以需要行列出來。

其他修補程式

上傳後，修補程式檔案內容的變動就限於標題資訊（也就是修補程式本身以外的所有東西）。例如，變更日誌項目可以變更，但 diff 命令的輸出則不能。

如果修補程式本身需要變更，就應建立一個有 ID 後的新修補程式檔案和新的修補程式字母。任何人都可以上傳修補程式來解決單一問題，因此可以針對相同問題提供其他修補程式。修補程式作者是唯一可以（或允許讓其他人）移除現有修補程式的人。移除修補程式是指移除修補程式檔案。

每個修補程式檔案都會獨立投票。新的其他修補程式必須自行取得投票，它們並不會自動繼承被更換修補程式的投票。

**CURRENT** 的修補程式可以在投票期間或之前隨時上傳。

投票期間

任何人只要能找到志工，就能發起投票期間

自願執行這些任務的人或單位會同意一個時間表，並在郵件清單上公告。時間表中最重要的部分是投票截止時間，會在投票截止時間清點票數，並建立新的版本。除非是 緊急事件，否則第一次的截止時間應該在公告後的至少三天後。

如果有足夠的票數而且沒有否決票，就可以使用與修補程式相同的投票規則變更投票截止時間，但不能投票決定目前的截止時間。

小組成員針對列於待審核事項中的程式碼修補程式進行投票和評論的頻率不受限制。個人對於事項的最後投票（如果更改了投票）會視為使先前的投票失效。

投票方式如下；

+1
可在下列條件下對程式碼修補程式投下正票，
  1. 已讀取程式碼修補程式標頭以查看其解決問題為何
  2. 已成功將其修補至CURRENT
  3. 未觀察到該程式碼修補程式造成任何不良副作用。

-1
否定票否決該程式碼修補程式。所有否定票都必須說明為何提出否定票是適當的。未說明理由的否定票視為無效。

否定票無法被推翻。如果您不同意否定票，您應該遊說提出否定票的人。打算對程式碼修補程式投否定票的投票者應立即讓小組知道他們的意見，以便在可能的情況下在投票截止日前解決問題。

收集選票

在最後投票截止日一到，投票協調員會立即統計選票。接著，投票結果會張貼至郵件列表。

要獲得核准，事項檔案必須收到至少 3 張正票和 0 張否定票。

投票協調員可以自行決定要忽略或接受遲交的+1 票。遲交的否定票沒有價值：只能用來試圖說服正票的投票者重新考慮。如果正票的投票者更改為否定票，該否定票即使遲交仍會生效。

釋出版本和公告

投票協調員將結果告知版本建置者後，NEXT 會透過將通過的程式碼修補程式套用到 CURRENT，進行其他通過的（非程式碼修補程式）事項指定的變更，將通過的事項描述新增至變更日誌，並增加版本編號來進行建置。

接著，版本建置者會將NEXT 上傳至 hyperreal，並將其放置至預先釋出目錄 (/httpd/dist) 中，檔案採用已壓縮和 gzip 處理的 tar 檔格式，檔名會命名為新版本號。新版本發布後會在私人郵件列表中公布。

版本公告後，建置者所犯的任何意外錯誤都可以無須投票即可修正，但必須向小組公布。

除非投票階段開始時另有說明，否則NEXT 預設為打算公開釋出。如果有人反對公開釋出，多數決投票將決定是否公開釋出。與其他投票不同，少數意見無法阻止公開釋出。

如果NEXT 要公開釋出，郵件列表中的所有人都應該盡量下載並試用它。NEXT 應該在建置和公告給小組後 24 小時內才公開釋出。

如果用來建置NEXT 的程式碼修補程式之一後來發現造成的問題比它修復的問題還要嚴重，應該將此事回報給小組，並延後所有公開釋出，直到取得關於如何解決問題的多數決決定為止。

緊急程式碼修補程式投票

如需進行緊急修補/票選會議以修復安全性問題，可能會需要略過上述的正常操作程序，以便在公共宣布問題前修補完成。任何群組成員都可以在郵件清單上公告緊急事件，如果得知嚴重問題，建議立即公告。任何群組成員都可以在緊急狀態下進行否決，以強制執行一般程序。

若要解決緊急問題所建立的修補程式，可以在建立修補程式並由作者測試後，直接從 Apache 的首頁連結。不過，如果否決原始修補程式，則必須移除或變更此連結。

在修補程式發布 24 小時後，或有三位 +1 票時，可以向大眾公布緊急修補程式的可用性，以較早到者為準。

延遲投票模式

有時，例如在早期開發週期，可能需要採行所謂的「延遲」投票模式。此模式基本上與正式投票程序相同，但實行「保持緘默即表示同意」的規則，若 48 小時內無人否決，即表示假設已取得一定數量的「贊成」票，即使這些票尚未正式收集。

正式與延遲投票環境可能會並存，有的主題可能需要採用正式投票，而有的則否。建議行使常理，而潛在爭議性高的修補程式不應在延遲投票規則下提出。

當修補程式提交者預計要採用延遲投票模式時，必須在修補程式提交中明確表示。

Rob Hartill 和 Roy Fielding
1995 年 9 月 3 日
1997 年 8 月 26 日由 Ken Coar 修改