Product SiteDocumentation Site

1.3. Debian 的內部作業

從有經驗的 Debian 發展者、Debian 套件裡的個別或集體作品、以及使用者的回饋,Debian 計畫產出豐富的結果。

1.3.1. Debian 發展者

Debian 發展者有多項職責,也是計畫的正式成員,對計畫的方向有極大的影響力。Debian 發展者至少負責一個套件,根據其時間及意願,可以自行參與其他團隊,取得更多的責任。
套件維護是相當團隊性的活動、極需要記錄與規範。實際上,必須與 Debian 政策 的標準相符。幸運的,很多工具可以協助維護者的工作。因此,發展者可以集中心力在其套件及其他複雜的工作,諸如除錯。
政策,是 Debian 專案中重要的元素,它是保障該散佈版軟體包品質與完美互通性的綱常。正因為有政策的約束,Debian 才能在愈來愈龐大的同時依然保持一致。然而,政策並非銘刻在石不能更改,要隨著 郵寄列表中型塑出的提案不斷演進。修訂案在所有關注的各方有所共識後,才會被一小群沒有編輯責任的維護者編寫 (他們只接納前述郵寄列表內眾 Debian 開發者接受的修改提案)。目前臭蟲追蹤系統內的修訂提案在此:
政策含包裝的技術細節。計畫的大小也引發組織的問題;由 Debian 憲法處理,即建立決策的結構與方法。換句話說,就是正式的治理系統。
憲法設定若干角色與位置,以及其責任與權威。Debian 發展者擁有選舉賦予的絕對決定權威,重大議題需要投票者的四分之三 (75%) 多數支持 (例如那些影響基金會文件的決定)。然而,發展者每年選舉 '領導人' 代表參與會議,確保各團隊間的協調。此選舉多伴隨密集的討論。領導人的角色不是任何文件能夠設定:候選人提出自己對此職位的看法。實務上,領導人的角色包括擔任媒體的發言人、協調 '內部' 的團隊、以及帶領整個計畫,發展者可以:要求領導人依多數決批准計畫成員的參與。
嚴格說來,領導人有絕對的權威;投票解決投票的問題;還沒有人負責的事都由領導人決定且可授權給他人。
成立以來,Debian 計畫已有多位領導人伊恩·默多克、布魯斯·佩倫斯、Ian Jackson、Wichert Akkerman、Ben Collins、Bdale Garbee、Martin Michlmayr、Branden Robinson、Anthony Towns、Sam Hocevar、Steve McIntyre、Stefano Zacchiroli 與 Lucas Nussbaum。
憲法也設立 '技術委員會'。發展者自身無法達成共識時由此委員會決策技術事宜。此外,當發展者無法解決自身職責所有的問題時,委員會就扮演顧問角色。祗有被爭議一方邀請後,才能涉入。
最後,憲法設立 '計畫秘書' 職位,負責各種選舉與爭議的投票事宜。
'爭議' 程序在憲法中詳列,從最初的討論階段至最後的計票。詳情見:
即使憲法建立了表面的民主,每日的運作卻大不相同:Debian 遵守自由軟體的蠢蛋進化論:做事的人決定怎麼做事。爭論解決問題的方法祗是浪費時間;選擇有用且滿意的方案才是王道…有能力的人就是這麼做。
這就是升級的唯一方法:做有用的事且顯示把事情做好。Debian '管理' 團體以增選方式管理,採用已有效奉獻且證明其能力的志願者。新的奉獻者看到這些團隊做了具有公共利益性質的工作就會主動加入協助。這就是 Debian 常被稱為 '任人唯賢'。
這種有效的管理方法保證在 Debian '關鍵' 團隊奉獻者的品質。不見得是完美的且偶而凸搥。選擇被團隊接受的發展者是隨興的,甚至不公平的。而且,不是每個人對這些團隊服務的期望是一樣的。有些人受不了等8天才能收錄新的 Debian 套件,也有人耐心等待3週毫無怨言。所以,有些團隊對 '服務品質' 經常不滿。

1.3.2. 使用者的積極角色

或許奇怪,需要在討論 Debian 計畫內工作者時加入使用者,答案是必須的:使用者扮演關鍵的角色。不祗是 '被動' 的角色,有些使用者執行發展版並定期報告指定問題的錯誤。其他的人更深一層提出改進的意見,以 '願望清單' 或送出稱為 '補丁' 的修正後原始碼 (見專欄 基礎 補丁,送出修訂)。
此外,很多對 Debian 滿意的使用者願意奉獻給這個計畫。每個人撰寫程式的能力不盡相同,有些人參與翻譯與審核文件。語文導向的郵寄名單在此。
靠著使用者的參與這些奉獻愈來愈有效。不斷地交換訊息,使用者不是孤立的個人而是一個真正的社群。從郵寄名單裡, (章 7, 解決問題與找到相關資訊 可看出詳情)。
使用者不僅自助 (也助人) 於直接影響他們的技術面,也討論奉獻 Debian 計畫的最佳途徑與協助其向前行 — 經常出現改進的建議。
Debian 不僅持續自我推廣,其使用者在擴散方面也居功甚偉,口耳相傳其名聲。
這些方法運作的不錯,在自由軟體的各個層面都有 Debian 粉絲:從在地 'Linux 使用者社群' LUGs 組織的安裝會 (協助新手安裝系統的工作坊),到 Linux 相關的技術會議等。
志工製作海報、小冊、貼紙及其他的推廣文宣,供社會大眾取用,部份內容在 Debian 網站可自由取用:

1.3.3. 團隊與子計畫

Debian 從開始就以原始碼的概念組織起來,每個套件都有維護者。隨時出現新的工作團隊,於子計畫內形成新的團隊,確保基礎建設的管理,以及流程運作不會被特定的套件綁住 (品質保證、Debian 政策、安裝器等)。

1.3.3.1. Debian 現有的子計畫

每個 Debian!子計畫是一群志工修改 Debian 供特定需求之用。選擇部份程式供特定領域 (教育、醫學、多媒體製作等) 使用之外,子計畫的目標還包括改進現有的套件、包裝漏失的軟體、調整安裝器、新增特定的文件,等等。
目前較流行的子計畫:
  • Debian-Junior,由 Ben Armstrong 製作,給兒童使用;
  • Debian-Edu,由 Petter Reinholdtsen 製作,針對學術圈的專門散佈版;
  • Debian Med,由 Andreas Tille 製作,專供醫護領域使用;
  • Debian Multimedia 針對音效與多媒體的工作;
  • Debian-Desktop 針對桌面與藝術作品的預設主題;
  • Debian GIS 照顧地理資訊系统應用程式與使用者;
  • Debian Accessibility,最後但也最重要,改良 Debian 滿足身心障礙者的需求。
隨著 Debian 子計畫的成長此清單將愈來愈長。由 Debian 基礎建設完全支撑,可以全然關注在加值部份,不需擔心與 Debian 同步的問題,因為他們在 Debian 計畫內發展。

1.3.3.2. 管理團隊

大部份的管理團體以相對封閉的增選方式招募成員。最好的加入方法是協助現有成員工作,表示您瞭解該團體的目標與運作方式。
檔案頭兒負責管理 Debian 套件的官方文件。簽收發展者傳來的套件,經過檢查後儲存在參照伺服器 (ftp-master.debian.org)。
他們也檢查新增套件的授權條款,確保在納入它們之前,Debian 有權散布它們。被要求移除的套件,由發展者經由錯誤追蹤系統與 ftp.debian.org '虛擬套件' 向團隊提出。
如眾所期待,Debian 系統管理者 (DSA) 團隊 () 對計畫內的多個伺服器負責。確保所有的服務 (DNS、Web、e-mail、shell 等)、Debian 發展者要求安裝的軟體、以及安全相關事宜。
名單大師 管理郵寄名單的電子郵件伺服器。職責包括新增名單、處理送回 (無法送出的育知)、以及垃圾郵件過濾器 (未授權的批次郵件)。
每個服務都有自己的管理團隊,通常是設立該服務的志工 (同時也撰寫通訊工具給自己用)。錯誤追蹤系統 (BTS)、錯誤追蹤器、alioth.debian.org (FusionForge 伺服器,見專欄 工具 FusionForge,合作發展的瑞士小軍刀)、在 qa.debian.orglintian.debian.orgbuildd.debian.orgcdimage.debian.org 等伺服器的服務。

1.3.3.3. 發展團隊、轉換團隊

不同於管理團隊,發展團隊較為開放,甚至可以說是置身於奉獻者之外。Debian 自身不新增軟體,計畫仍需要外部軟體滿足其需要。當然,仍是在自由軟體授權下發展,這些工具使用被自由軟體世界驗證的方法。
Debian 發展自己的小軟體,但卻是重要的軟體,其名聲遠超越 Debian 計畫本身。dpkg 是個例子,它是 Debian 套件管理程式 (事實上,它是 Debian PacKaGe 的縮寫,讀成 'dee-package'),另一個是 apt,自動安裝 Debian 套件的工具,檢查其相依性,保證安裝後與系統一致 (其名稱為 Advanced Package Tool 的縮寫)。然而,它們都是由小團隊撰寫的,祗需要高階程式技巧就能瞭解該等程式的運作方式。
最重要的團隊可能是 Debian 安裝計畫,debian-installer,2001年問世以來就是重要的部份。以一個程式安裝十多種架構下的 Debian 不是件簡單的事,需要很多奉獻者才能完成它。每個架構需有自己的啟動程式與載入程式。透過 郵寄名單,在 Cyril Brulebois 領導下,完成這些工作。
這個 (極小的) debian-cd 程式團隊的目標更謙虛。由很多 '小小' 的奉獻者負責其架構,因為主要的發展者無法知道全部的細微之處,也不知道從CD-ROM 安裝的正確方式。
需要多個團隊彼此合作才能夠將程式包裝起來:以 為例,企圖保證 Debian 計畫的每個層面都達到既定的品質。 根據各地的建議列出 Debian 政策。負責每個架構的團隊 () 編繹所有的套件,若有需要,再改編供特定架構使用。
其他的團隊管理最重要的套件以免重擔放在單一團隊的肩上;在 C 程式庫與 ,C 編繹器 郵寄名單,或 Xorg 在 (此社群以 X Strike Force 聞名)。