將OpenJDK遷移到GitHub，這個主意不錯！
這個月的OpenJDK社區出現了一個新的JEP(JDK Enhancement Proposal) ， 即JEP 369 ： 把OpenJDK的源代碼遷移到GitHub。
原來的OpenJDK源碼是存放在Mercurial (hg) 中的，這是個老牌的分布式版本管理系統，非常容易上手，快速，簡單。
hg用得好好的，為什么要遷移呢?
主要有這些原因：
1.Git元數據更小，jdk目錄的.git 是300M， .hg是1.2G。
2.GitHub在網絡和可用性方面有出色的表現，clone和pull的時間會大大減少。
3. GitHub提供了良好的結構化的API，可以和各種工具輕松集成，如編輯器(Emacs,VSCode,Atom)，IDE(Eclipse, Visual Studio , Intellij),命令行等，讓程序員和平臺輕松交互。
4. 把OpenJDK放到GitHub，能極大地拓展OpenJDK社區。
其實說白了就一句話：GitHub是大勢所趨。
我一直認為，如果沒有GitHub這個全球最大的“同性交友網站”作為Killer，Git是不會這么火爆的，雖然它是Linus本人親自操刀開發的。
但是一旦火起來，那就出現“強者更強”的效應，大量的項目遷移到GitHub，開發人員大量涌入，大量的周邊工具會被開發出來，主流的編輯器，IDE都會大力支持，最后吃掉整個市場。
聯想到最近微軟加入OpenJDK社區， 現在OpenJDK又想入駐屬于微軟的GitHub，這事兒有點意思。
最后能不能遷移成功，讓我們拭目以待。 但這不是今天的重點，今天的重點是我想說一下看了這個JEP的格式后引發的一些聯想。
有很多人問過我這么一個問題：在枯燥的業務需求開發之外，想升職加薪，想給自己的簡歷增光添彩以便跳槽，該怎么辦?
一個重要的辦法就是你要推動著項目能做出一點改變，例如實施單元測試，敏捷，DevOps等等。
當你有了一個想改變的想法，怎么去實施呢? 可以找領導談，努力說服領導，可以在項目開會的時候提出來，說服組員。如果你有這樣的表達能力和溝通能力，那就不用浪費時間繼續看了。
否則請看JEP這個優秀的模板：
1.摘要
在GitHub上托管OpenJDK的代碼倉庫，包括JDK11 以后的feature relase, update release......
2.目標
在GitHub上托管OpenJDK的代碼倉庫 在每個push之前運行jcheck 保持所有元數據 確保工作流和現在的類似 ......
3.非目標
不改變OpenJDK社區的issue tracker,wiki .....
4.成功的度量標準
更快的clone和pull，更好的可用性......
5.動機
為什么要遷移到外部的代碼托管商?
.....
為什么要選擇GitHub?
......
6.描述
具體的做法
7.可選方案分析
GitLab EE， BitBucket.....
8.風險
遷移的風險是Skara項目要考慮的首要因素，下面的一些設計決定保證我們不會被外部的平臺(如GitHub)鎖定:
......
看起來非常專業，對不對?
這個模板中包含了想要做的事情的方方面面，需要深入地調查、分析、對比，然后才能做出來，而不僅僅是拍腦門：咱們做這個吧!
有些人很討厭寫文檔，如果我們在工作中提建議的時候，也能給領導呈現這樣的文檔報告，總結分析了這個問題的各個方面，是不是大大增加了被接受的可能性呢?至少在這個基礎上進行小組討論會更加有效。
看到了項目的問題和困難，只是抱怨沒啥用處，能夠推動做改變的人才是真正厲害的人，改變的時候要有策略，要有扎實的分析和調查。
從今天開始，仔細想一想，你能推動項目做出哪些改變?立刻開始行動吧!
【本文為51CTO專欄作者“劉欣”的原創稿件，轉載請通過作者微信公眾號coderising獲取授權】
