GCIN 和 HIME... 事情怎麼會變這樣？

[Tetralet]

最近 GCIN 和 HIME 事件搞得有點沸沸揚揚。
在事情差不多平息後，我想，身為事件的主角之一，敝人有必要跳出來說明一下。

還不曉得發生什麼事的可以到這裡來看看：

　http://www.ubuntu-tw.org/modules/newbb/viewtopic.php?topic_id=45446
　# HIME INPUT METHOD EDITOR, HIME (姫) 專案，開始！

　http://www.ubuntu-tw.org/modules/newbb/viewtopic.php?topic_id=45580
　# 關於ubuntu-tw社群論壇HIME發佈文章12/15爭議事件的部份經過

　http://hyperrate.com/thread.php?tid=25859
　# gcin改名了?

Fork GCIN？引火線...

　讓我們先岔開話題，先談談 Evilvte 和 LilyTerm 好嗎？

　　Evilvte：基於 GTK2/VteTerminal 的 X Terminal Emulator。

　　LilyTerm：基於 GTK2/VteTerminal 的 X Terminal Emulator。

　光看這簡介，就知道 Evilvte 和 LilyTerm 是同質性多高的軟體。
　Evilvte 則是由 caleb（也是事件主角之一）開發的，
　LilyTerm 是由敝人在差不多時間開發的。
　因為同質性太高，我們理所當然變成了競爭對手。
　我常常在笑 Evilvte 真的是怪胎才會搞出來的軟體，
　caleb 則是回說 LilyTerm 才是複雜到令人受不了。
　雖然這樣說，但其實個人認為，
　LilyTerm 和 Evilvte 與其說是對手，我覺得更像是伙伴間的關係。

　比如說，LilyTerm 和 Evilvte 使用了相同的 icon。
　這 icon 原本是我拿 GIMP 隨手亂畫的，
　因為 X Terminal Emulator 就像是過時代產品，
　所以就畫得好像是老舊的電視機，然後 caleb 就要了去。
　結果就變成兩套同質軟體使用相同的 icon 的爆笑景像。
　不過現在 Evilvte 有新 icon 了，可惡怎麼沒有人也來幫我畫一個？

　在開發期間，若遇到什麼難解的問題，
　我就去偷瞄 Evilvte 的程式碼，
　或乾脆直接問 caleb 有沒有啥 idea 或解決方案。
　看到有啥問題也會順便送送修正檔給 caleb。
　而 caleb 也時常說感謝 LilyTerm 他拿了許多程式碼去用，
　但也真虧他看得懂！ XD
　有時候他遇到一些要求很多的使用者他也會乾脆建議何不試用 LilyTerm 看看？ XD
　而我當然是當仁不讓得接收了（我怎麼沒看到人？）
　若遇到啥奇怪的問題時，有時感覺是 GTK2+/GTK3+ 或 VTE 的 bug，
　他也會和我一起討論，看看我們誰有沒有辨法解決。
　其實 #gcin 上的話題常會圍繞著 Evilvte/LilyTerm 轉，且毫無違和感。
　我們是競爭對手沒錯，但我們不是敵人，卻更像是同舟共濟的戰友 XD。

　Evilvte 和 LilyTerm 就是這樣的一種微妙的既合作又競爭的關係。
　雖然講來有點神奇有點不可思議，但事實就是這樣擺在眼前。

　其實，這也就是 FreeSoftware 的魅力之一。
　因為有原始碼在手，什麼都是公開透明的，沒什麼可以藏私或隱瞞的，
　那麼其實可以更放開胸懷去接受人和人之間的關係。
　反正去斤斤計較又有什麼意義？code 會說實話，不是嗎？

　因為有了這種經驗，在決定 fork GCIN 之初，
　其實敝人就將 HIME 定位為『GCIN 的 Clone 版，不過有一些自己的小修正』。
　敝人信任 eliu（GCIN 的原作者）是個大器的人（其實即使到現在還是這麼認為），
　也相信相同的美好體驗一定會在 GCIN 和 HIME 之間發生。
　也就是說，其實一開始，敝人就沒有遺棄 GCIN 的打算！
　只是想收集一些我們認為不錯的修正但 eliu 不收只好自己套用到 HIME 上去這樣。

　也因此，我在 HIME 0.9 版開發完成後，
　就想立即把一些修正回饋給 GCIN。
　後來 eliu 自己包的 deb 其實也有些小問題可能要去提醒一下。
　有掛在 #gcin 或 #hime 的人應該可以出來做証。
　但因為時機有點敏感，所以想先壓個幾天再說似乎比較好。
　不過看事態發展弄成那麼尷尬，這些 patch 要送出去真的有點困難了... orz

Replace GCIN？引爆點！

　而整個事情的引爆點大家可以去看看，
　簡單得說有某位熱心的 Ubuntu 使用者想把 HIME 推進 Debian 裡，
　但可能對於 Debian 的一些比較專門的固定用語不太熟悉，用辭也不是很恰當。
　然後不知是誰把這個人誤認為是 HIME 開發團隊的 caleb，於是就開罵了，
　事情瞬間一發不可收拾。
　整個過程太令人難過我不想再重述一次了。

　在整個過程中，您應該可以發現 HIME 開發團隊全員一開始就選擇沉默。
　雖然明顯是一些無謂的誤會，
　但我們 HIME 開發團隊無意加入紛爭，也不想擴大戰線，
　最重要的是我們不想和 GCIN 開戰。
　只有其中很明顯指名道姓罵 caleb 時，
　正在火線上的敝人才不得不出言指正一下。
　但很明顯的，即使到現在，HIME 團隊對 GCIN 還是沒有任何敵意的！

關於 debian.luna.com.tw 上的 GCIN/HIME 套件

　另外一個爭議點是 Luna's Debian Archiver，
　http://debian.luna.com.tw 用 HIME 把 GCIN 替代掉了。
　當您是使用 Luna's Debian Archiver 這個由敝人架設的私人 apt 站台時，
　在軟體升級期間，會用 hime 把 gcin 給替代掉。

　其實，維護 GCIN 套件是蠻累人的。
　首先 eliu 發新版後，敝人會先下載來看看 diff，
　當然有些是看不懂 XD
　然後再打包試跑大略看看有什麼新功能或會不會出了什麼新問題，
　如果真的有發現問題會先寫個 patch 看有沒有修正，
　最後確定應該沒什麼問題後會再拿去所有編譯環境試包看看。
　若有問題當然又要修，直到真的沒問題了才會真的把 deb 上架，
　有必要時再把 patch 往 eliu 那裡回報；
　但這往往要花上幾個小時、甚至好幾天的時間。

　這也是 GCIN 的 deb 常常會晚上幾天的主因。

　當然不是每次都那麼麻煩啦，
　有時光看 diff 就知道應該不會出事，
　就會直接打包成 deb 上傳。不過還是很累人就是了。

　而在 HIME 計畫開始之初，
　我就下定決定會把 GCIN 從 Luna's Debian Archiver 給 drop 掉。
　這並不是因為了要搶 GCIN 的 User，
　而是因為我很顯然會不再使用 GCIN 了，
　所以我如果還在包 GCIN 的 deb 的話，
　這些 deb 檔將會缺乏測試和上機實測，這比乾脆不打包 GCIN 更不負責任！
　就像如果有家麵店的老闆從不試吃自家的麵，您能放心去消費嗎？

　當然，還有個私心的目的是看能不能找到誰來維護 Debian/Ubuntu 的 GCIN/HIME。
　被 orphan 的套件很可憐的！像 LilyTerm 就沒人要包... (泣)

　那剩下的問題就是該不該用什麼自動更新了。

　其實敝人事前評估過，
　就如上文所說，因為 HIME 根本就是 drop in replacement of GCIN，
　所以自動更新基本上是可行的。
　在 Debian 官方歷史上用某個套件取代另一個套件也不是啥新鮮事，
　有名一點的像是用 eglibc 取代 glibc、
　用 IceApe、IceWeasel、IceDove 取代 Mozilla Suit、Firefox、Thunderbird；
　近期的像是用 fpm2 取代 fpm、用 geeqie 取代 gqview、
　用 wodim 取代掉 cdrtools 之類的不及備載。
　所以這種事根本沒什麼好大驚小怪的。重點是該不該這麼做罷了。

　當然我有考量了一下。與其把 GCIN 的 deb 都丟掉，
　讓使用者晾在那裡一年半載才發現本站已沒有在維護 GCIN，
　不如善用 Debian/Ubuntu 的套件管理系統，
　讓使用者知道本站已用 HIME 替代 GCIN 也不錯。
　所以就採取了一些步驟：

　　首先，我先努力在各大網站、PTT、個人的 blog 上發表了 HIME 計劃的推坑文，
　　裡面有用了一段篇幅介紹：

　　　『在使用 apt 更新的過程中，
　　　請特別注意到應該會自動得把所有 gcin 套件升級為 hime，
　　　剩下的 gcin-* 套件則只是虛擬套件，您可以放心得移除。』

　　這樣有些消息比較靈通的使用者應該會早早知道有這回事了。

　　並且，我故意讓敝站的 HIME deb 套件和 HIME 官方並不是同步推出，
　　重點就在爭取一點緩衝期。（不過事後諸葛，緩衝期太短了。重大失誤。）

　　接下來，讓 GCIN 2.5.1-0~2 變成虛擬套件，
　　因為第一次包虛擬套件不太熟，一直包到 2.5.1-0~4 才包得比較好。orz
　　其中的 changelog.Debian.gz 包含了以下訊息：

　　　* GCIN was droped from http://debian.luna.com.tw
　　　　and won't be maintained anymore.
　　　　Please consider to use HIME package instead. Thanks!

　　那麼，一些比較細心的使用者在安裝了新版 GCIN 前
　　應該就會注意到這個重大變化了。
　　（給 Debian 使用者貼心叮嚀：
　　　請務必安裝 apt-listchanges 套件！
　　　而 Ubuntu 的套件管理程式好像預設就有這個功能了，不確定。）

　　當然，這還是不敢保証每個使用者都那麼細心一定會看到，
　　但還好本站 Luna's Debian Archiver 從來不加 PGP Key，
　　所以在升級 GCIN 套件的同時，系統一定會警告有新增 HIME 套件，
　　然後系統也會要求使用者確認 [y/N]（預設值是 N）
　　應該很少有使用者看都不看發生了啥事就按 Y 吧？

　　所以我認為這根本不能說是強迫升級吧？

　　當然，我也知道一定會有使用者不小心就把 HIME 裝進去想換回 GCIN。
　　所以我在那篇推坑文中也有寫到如何自行打包 GCIN deb 的教學。

　　並且，若真的想用 GCIN 舊版套件的話，
　　其實所有的舊版套件都可以在使用者的 /var/cache/apt/archives/ 中找到，
　　然後手動安裝那些套件應該也不算是難事。

　　最後，如果使用者連舊版的 GCIN deb 也找不到、也不知該如何安裝的話，
　　那其實把 Luna 的 Debian Archiver 移掉，
　　用 Debian/Ubuntu 的套件管理工具安裝官方版的就好了。
　　其實，就算沒把 Luna 的 Debian Archiver 移掉，
　　用 apt-get install gcin 應該就會安裝到 Debian/Ubuntu 官方版的 GCIN，
　　而不會一再安裝到 Luna 版的虛擬套件。

　所以經過種種考量，
　敝人才會決定在 Luna 的 Debian Archiver 上用 HIME 取代 GCIN。
　但相反的，若 Debian/Ubuntu 官方這麼做的話個人則真的會持反對態度。
　官方的做法不像私人站台，做法必須更周延一些才好。

　當然，以最後的結果來看，我實在把事情想得太簡單了。
　有使用者回報說是，系統問也不問就自動更新上去了，
　也有人回報說無法降級到官方版... （有人能告訴我為什麼嗎？），
　所以敝人又在最短時間內包了新的 deb 套件丟上去。
　不過因為在 Debian Lenny 下編譯失敗，所以只能先丟舊版的。
　新版的可能要再等上一等。

　但可以保証的一點是，敝人絕對不是想用這個方法替 HIME 衝使用者人數，
　用這種白爛方法風險也未免太高！
　並且，就拿 LilyTerm 為例，
　我也只是偶爾用自己的 blog 報告一下 LilyTerm 的開發進度和一些心得，
　絕少去別的網站打廣告推廣啥的。
　對自己開發的 LilyTerm 尚且是這種態度，
　對 HIME 當然就更不可能用這種那麼粗糙、那麼容易被看破手腳的方式去推廣。

　但總而言之，結果事與願違就是了。

　在此敝人要對 HIME 團隊說一聲抱歉。
　要不是我一個人一廂情願胡搞瞎搞，
　就不會被人誤以為 HIME 要取代 GCIN 啥的，
　那麼 HIME 團隊應該就不會受到那麼大的傷害了。
　也要對 HIME 團隊說聲『讚！』，
　你們能忍耐住不發火也不反駁，表現真的太令人激賞了。

　也要對 GCIN 的 eliu 說一聲抱歉。
　HIME 只是想收集些 GCIN 不收的 patch，
　有些處理上，像未事先溝通好之類的，也真的是我們的錯，
　但敝人真的沒料到事情會鬧成這麼僵。

這整個事件發展完全在敝人的預料之外，
風波平息後最無辜的 HIME 團隊反而成了最大的受害者！
從頭到尾沒做錯什麼事卻被一大群人圍攻，莫名其妙整個形象大壞，
並且也導致 GCIN 和 HIME 似乎只好分道揚鑣，自己玩自己的了。
而這根本不是原本我們 HIME 團隊 fork GCIN 的原始目的！
我們只是想修修改改惡搞出一個我們喜歡的 (偽) GCIN 罷了，
連 HIME 這個名字都很惡搞，根本無意和 GCIN 鬧翻。
但事情搞到這樣卻似乎是難以收拾了...

在此把這些寫出來並不是說想說明什麼指責什麼反駁什麼，或再引起另一起風波。
只是覺得對這一切感到很難過罷了...