将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）锁定: 

......

看起来非常专业，对不对？ 

这个模板中包含了想要做的事情的方方面面，需要深入地调查、分析、对比，然后才能做出来，而不仅仅是拍脑门：咱们做这个吧！

有些人很讨厌写文档，如果我们在工作中提建议的时候，也能给领导呈现这样的文档报告，总结分析了这个问题的各个方面，是不是大大增加了被接受的可能性呢？至少在这个基础上进行小组讨论会更加有效。 

看到了项目的问题和困难，只是抱怨没啥用处，能够推动做改变的人才是真正厉害的人，改变的时候要有策略，要有扎实的分析和调查。 

从今天开始，仔细想一想，你能推动项目做出哪些改变？立刻开始行动吧！

相关文章

往期精彩回顾

我是一个线程

我是一个Java Class

面向对象圣经

函数式编程圣经

TCP/IP之大明邮差

CPU阿甘

我是一个网卡

我是一个路由器

一个故事讲完HTTPs

编程语言的巅峰

Java：一个帝国的诞生

JavaScript：一个屌丝的逆袭

负载均衡的原理