这个月的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获取授权】
