Introduction to Ubuntu Development
Ubuntu是由數千個組件所組成的，有數種的程式語言。每個組件，不管是軟體函式庫，工具或是GUI程式，都可以取得他的原始碼(source code)。在大部分的原始套件(source package)裡面，都包含了兩個部分:
- source code
- metadata。
Metadata包含了套件的相依性，版權和授權資訊，還有如何去建置這個套件的文件。當你編譯完這個套件以後，就會得到一個二進制套件(binary package)，也就是一個可以安裝的.deb檔。
每當一個新版本的軟體被release，或者是有人更改了source code並且發送到Ubuntu以後，這些source package都必須被上傳到Launchpad上的build machine去編譯。
編譯完的二進制套件將會被上傳到其儲存區(archive)和各個國家的的鏡像(Mirror)。所以在 「/etc/apt/sources.list」裡的URL將會被指到這些鏡像上。每天對於不同的Ubuntu flavours都會有數個images(影像檔)被建立出來。你可以將這些image放到你的USB裡，也可以燒成DVD，也可以用「netboot image」，或者是用來去更新你的智慧型手機和平板。
Release cycle
Ubuntu的研發都照著目前的release cycle ，Canonical每6個月就會釋出新版的Ubuntu。 在每一期的Freeze date之前，通常工程師們都會減少太大的改變。而Feature Freeze則是在產品週期過一半以後第一個遇到的大Freeze。而在「 Feature Freeze 」時，大部分的feature都大概都被完成了。
而接下來的周期都會專注在bug的修復，接下來是使用者介面，文件，kernel都會被一一被frozen，接下來Beta版就會開始進行測試。當Beta版被釋出後，接下來就只剩下一些比較嚴重的bug會被修復，然後就會開始挑一版比較好的版本準備做最後的釋出。
數以千計的原始套件，百萬行的source code，數百個貢獻者(contributors)都需要有很多的交流以保持高規格的產品品質。通常在每個產品釋出周期前中期，都會發起一個聚會，所有的開發者和貢獻者都會聚在一起討論下一期版本的功能。
討論下一期的功能時，Spec就會被記錄下來，細節包括:所有個假設，架構，如何實做，必須要的改變和如何測試等等相關議題。這些過程全都會在公開的場合進行，所以你也可以在遠端參加這場會議，聽他們的視訊廣播，可以與參予者交流，訂閱Spec的修改記錄，這樣你就會一直了解最新的狀態。
但是並不是每個改變都需要開會去討論，尤其是Ubuntu是非常依賴於其他的案子的(eg. Debian)，所以這就是為什麼所有的貢獻者都必須保持聯繫。大部分的團隊或專案都用專用的mailing lists，以避免太多不相關的訊息。而如果需要更多及時的討論，則開發者和貢獻者將會使用Internet Relay Chat(IRC)交流，所有的討論都將會是公開的。
另一個重要的工具就是「bug reports」。每當在套件或架構裡面有bug被發現後，發現的人就會將這些報告給送到Launchpad上。所有的資訊(包含了重要性，狀態和指派人)都會被收集到這個report上。所以這就對於套件和案子上的管控達到一個很好的效果。
Ubuntu and Upstreams
大部分Ubuntu裡的軟體都不是由Ubuntu的開發者所開發的，都是由外部的Open source的開發者開發完以後，在整合到Ubuntu裡面。而這些非內部Ubuntu的案子，稱為上游「Upstreams」，因為他們就是open source的上游，然後Ubuntu這邊只是負責整合。和這些upstream之間的關係是非常重要的，因為Ubuntu並不是只是從Upstream這邊去取得code，反向來說，Upstream也會從Ubuntu和其他貢獻者這邊取得bug report和patches。
Ubuntu最重要的upstream是Debian。因為Ubuntu就是依據Debian的設計和封裝架構(packaging infrastructure)所建立出來的，以傳統來說，Debian總是有專門的維護者(maintainers)或維護團隊(maintenance teams)。當然在Ubuntu也有相關的團隊，自然來講當然也會每個開發者都會專精於特定的領域，而只要有能力和有意願的任何人都可以參加。
如果你想要當Ubuntu的貢獻者其實並不會很難，而且這經驗應該會讓你學到很多東西。並不只是讓你學到很多新東西，而且也可以為了百萬名使用者解決很多問題。
Open source的開發是在世界上的分散地區進行的，而目的和專注的區域都不太一樣。舉例來說，某個Upstream正在開發一個很大的功能，但是目前Ubuntu因為準備要發布下一版了，所以無法把這個新功能給整合進去，這就是為什麼要用分散式開發(Distributed Development)，這樣開發就可以在不同的branch上進行，等到穩定一點，討論的比較充分後，在把他整合進來。
就如同上圖所示，Ubuntu先用現有的版本釋出，加入bugfix以後在回饋到Upstream，然後就會在下一版的Ubuntu裡面有新版Upstream的功能加上之前的bugfix了。
Get involved
如果想要幫忙在Ubuntu的bug有貢獻，可以參考以下步驟:
- 首先你需要取得套件的source code。
- 修復這個bug。
- 為這個修復(fix)寫文件，這樣其他的開發者和使用者將會比較容易了解你修復了什麼。
- 建置這個套件以供測試。
- 測試完後，你可以發送這個修復到目前的開發版本上。
- 其他有上傳權力的開發者將會檢視(review)並且整合到Ubuntu裡面。
流程圖如下顯示：
通常在找一個bug的解法時，去檢查upstream是否已經有人注意到這個問題是個不錯的主意，如果沒有的話，就在盡你最大的努力去解決他吧。
如果要回遷(backported)到舊版本，通常又會牽扯到其他的問題，但是如果這個版本還在支援的期限內，則還是會轉送給Upstream處理。
對於Ubuntu的開發成功來說，最重要的需求/訣竅就是：『making things work again』，並且不要害怕去讀文件和問問題，好好當一個團隊的成員和喜歡去探索你的工作。
如果你要問問題的話，可以到 mailing list 『[email protected]』 和 IRC network『freenode』上的channel 『#ubuntu-motu』， 你將會找到很多同好，大家都是想要讓世界變得更好，想要讓open source軟體更好。
Ref:
http://packaging.ubuntu.com/html/introduction-to-ubuntu-development.html