這次的系列要嘗試瞭解 bug 追蹤的奧妙，進而探索 bug 的生命週期
希望能從探索的過程中領略開源組織協作的生態

為何挑選 Bugzilla 來做介紹？

接續昨天針對 GNOME-Logs GSoC 的解析，我們要來嘗試瞭解在 GitHub ISSUE 以外的 bug 追蹤系統：Bugzilla，想介紹的原因是在昨天分析的過程中有注意到 Bugzilla 有出現在 issue（github/gitlab），而且不少開放原始碼的組織就是透過 bugzilla 來管理 bug 的「報告、追蹤、討論」，如果能夠學會 bugzilla 應該是挺划算的投資，因此勾起筆者想寫篇針對 bugzilla 的介紹，並期望達到以下目的

• 瞭解 bugzilla 的使用方式，並嘗試實際跑過一次流程
• bugzilla 對 bug 控管的設計思維
• bug 在 bugzilla 的生命週期

關於 Bugzilla

Bugzilla 是由 Mozilla 於 1998 以 Mozilla Public License[註1] 釋出的一款 Bug 追蹤系統，其程式碼是由 Perl 撰寫並且目前維護在 GitHub 上，根據官網統計公開 bugzilla 的公司、組織、專案約 137，如果包含非公開的可能有十倍以上，而在 137 家中有相當多知名的組織，如 GCC、GNOME、KDE、Red Hat、Eclipse、Gentoo、Linux Kernel...等等，詳細列表可以在 Link 瞭解

• Wikipedia
• 官網
• GitHub
• Documentation
• Bug Report for Bugzilla

以上是相關超連結，如果你點進 GitHub 進去應該會發現沒有 Issue 的區域，這是因為 bugzilla 本身的 bug 是透過 bugzilla 來管理～挺有趣的！

如何使用 Bugzilla？

今天的示範會遵從官方文件的指引來走。而嘗試的 bugzilla 就用官方自身維護的 bugzilla 來嘗試，雖然 GitHub 有提供一個類似沙盒的連結，不過目前是無法使用的狀態。
因此今天的觀察筆記會站在 Mozilla 的 bugzilla 的立場來紀錄，內文的 bugzilla 就是指 bugzilla hosted by Mozilla

這幾天會來深入官方指引一探究竟

• 第二章 User Guide
  • 2.1. Creating an Account
  • 2.2. Filing a Bug
  • 2.3. Understanding a Bug
  • 2.4. Editing a Bug
  • 2.5. Finding Bugs
  • 2.6. Reports and Charts
  • 2.7. Pro Tips
  • 2.8. User Preferences
  • 2.9. Installed Extensions

一開始會需要先註冊一個帳號，在其帳號註冊頁面可以看到一些注意事項

• 請閱讀 如何撰寫 Bug Report
• 在 bugzilla 上你的留言、E-mail 都是公開的，請知悉這些規定。(也因為如此有些人會使用備用 E-mail)[註2]
• 在 bugzilla 的產生的內容需遵守 Moziila 的開源政策來授權
• 請遵守相關的禮儀與社群參與指導原則

這邊值得注意的是第三點
如果對社群參與不熟悉的朋友可以嘗試去了解第三點的授權政策，，對於參與開源專案來說，通常貢獻的內容都必須遵照社群定義好的授權條款，另一個常見的名詞 Code of Conduct 也就是行為準則，在 GitHub 上進行 PR ，你的程式碼也是 under the licence in the project。

在註冊的過程中在欄位裡面有個 REALNAME，文件裡面也提到建議填寫真實名稱，目前不曉得為何要這樣做，筆者會再找朋友瞭解看看這項建議的用意。

Once you confirm your registration, Bugzilla will ask you your real name (optional, but recommended) and ask you to choose a password. Depending on how your Bugzilla is configured, there may be minimum complexity requirements for the password

建立完成後初始頁面如下

2.1 Filing a bug

這章節開宗明義就說

Years of bug writing experience has been distilled for your reading pleasure into the Bug Writing Guidelines.
看來得好好深入 Bug Writing Guidelines 來提煉前人的經驗了！

先讓我們在這邊告個段落，因為 Landfill 官方提供的沙盒掛了，希望能找到代替的方式，不然不能實作看看有點可惜，因此今天第二章的介紹就先到這邊，明天會從頭把第二章的內容接起來介紹。

如果有朋友知道哪邊可以練習 Bugzilla 的使用，再請留言提供給我，謝謝 :>

結語 & 預告

今天在看文件，發現 Bugzilla 本身並沒有中文化，因此明天在進行第二章介紹前會先回報 Bugzilla 文件中文化的可能性，再接續今天 bugzilla 的指引，一步一步去瞭解 Bugzilla 的使用方式。而另外這個主題也會有衍伸的題目「如何回報一個好的 bug」，這應該會是相當重要的議題，筆者會在思考何時端出這個章節進行介紹。

備註與參考

[註1] 該協定融合了BSD授權條款和GNU通用公眾授權條款的特性，追求平衡專有軟體和開源軟體開發者之間的顧慮。
[註2] 底下是註冊帳號，收到的信件再次提醒的內容
PRIVACY NOTICE: Bugzilla is an open bug tracking system. Activity on most
bugs, including email addresses, will be visible to the public. We recommend
using a secondary account or free web email service (such as Gmail, Yahoo,
Hotmail, or similar) to avoid receiving spam at your primary email address.

[Reference]
Icon provided in https://www.bugzilla.org/img/buggie.png