Problem Report System

一個團體會需要有個管道和參與的人互動，像是詢問問題、回報問題、提供建議。對於不同的規模，有不同的方法。

在開放原始碼的社群裡面，如果團體很小 (發展者不到三個人)，可以透過郵件論壇或是聊天室互相討論。像是 lighttpd 的發展就蠻接近這種模式。

但如果團體比較大，發展者有兩位數甚至三位數，這時候就要有工具幫忙，讓使用者回報問題、提出建議時的紀錄可以有系統的整理出來。這種系統有的時候叫做 Problem Report System，有的時候叫做 Bug Tracking System。像是 Mozilla 在發展軟體所使用的 Bugzilla，或是下面所提到的 GNU GNATS。

我接觸 GNU GNATS 是因為 FreeBSD 使用 GNU GNATS 管理整個專案。

參與 FreeBSD 的發展有幾種方法，一種是擁有 freebsd.org 的帳號，像是 ijliao、leeym、clsung。有時我們叫他們 “committer”，因為這些人可以直接存取 FreeBSD CVS Repository (也就是 “commit”) 以及 GNATS 資料庫。

而另外一種沒有帳號的人，則可以透過 send-pr 將想要改的東西送入 FreeBSD 的 GNATS 資料庫，由 committer 看過以後再 commit 進 CVS Repository，所以我們叫這些人 “submitter”。

我因為參與幾個 FreeBSD ports 的維護工作而玩過 GNU GNATS 的一部份：用 FreeBSD 的 send-pr，將要修改的步驟 (通常就是附上 patch files) 透過 E-mail 送到 FreeBSD 的 GNATS database 裡。送進去後系統會給我一個 PR number。如果有任何 committer 更新這個 PR，我會收到信件通知。

資工系的系計中助教大約有二十個人，這二十個人並不是全部處理同樣的事情。有些人處理 FreeBSD，有些處理 Linux 或 Sun 工作站，有些則處理 Netnews 或是 BBS。我覺得把 PR System 搬進資工系系計中來用，應該可以幫助我們處理一些事情，於是我就在 freshmeat 上看各家 PR System 所使用的情況，以及建構系統的複雜度。

既然這篇不斷的講 GNU GNATS，那當然是因為最後我們用 GNU GNATS。會使用 GNU GNATS 的原因在於運作很簡單：

• 透過 send-pr 產生 PR。事實上 send-pr 只是產生一個範本，然後呼叫編輯器 (vim、joe、…) 讓你填寫欄位，最後以 E-mail 送到 GNATS Database 裡。
• 透過 edit-pr 修改 PR。事實上 edit-pr 會產生一個檔案，然後呼叫編輯器，你修改完欄位以後他會檢查哪些欄位被修改了，再修改 GNATS Database。

整個系統的要求極低，不需要 PHP，不需要 MySQL。對於系計中助教而言，在 Unix 上用編輯器修改檔案並不是難事，所以對於助教看起來一切 okay。

但這個年代你不可能叫使用者透過 send-pr 一個一個填，而 GNU GNATS 本身沒有網頁界面，所以必須找個軟體，可以讓使用者透過網頁介面產生 PR，以及查詢目前 PR 處理的進度。

我找到 Gnatsweb 這套軟體，但發現他的介面並不好用，回頭來看 FreeBSD 用哪一套的時候，卻發現 FreeBSD 自己寫了一套給自己的 GNATS Database 用 !@#$%^…

所以我花了一些時間寫了一個網頁介面，可以讓人 Submit & Search，順便練習怎麼寫各家瀏覽器都可以用的 Javascript，然後試著用 Yahoo User Interface Library，學著減少不斷重新造輪子的問題。同時把 RSS 2.0 實做出來：http://help.cs.nctu.edu.tw/pr/。

PS：這篇文章沒有意義，純粹記錄事情而已。