TensorFlow技术主管详解:Google是怎样管理开源软件的

唐旭 编译自 O’reilly 量子位 出品 | 公众号 QbitAI

TensorFlow开源一年半以来,在GitHub上已经有了820位贡献者,close了5192条issue,还有1033条开放着。

同时,如果所有TensorFlow团队成员都在GitHub上,而且属于这个组织的话,它在Google内部还有着一支75人的团队。

一支人数不算少的全职团队,是如何和数量众多的开源贡献者共同改进TensorFlow的呢?团队的技术主管Pete Warden带着深深的怨念,在O’reilly网站上发表文章,讲述了他们是如何维护TensorFlow开源社区的。

以下内容编译自Warden的文章:

开源可不只是把代码往GitHub上一扔,然后等着别人去用它就完事了。道理我都懂,可直到在谷歌成为TensorFlow团队的一员,我才真正开了眼:要围绕一个软件打造出一个社区,要考虑的因素实在是太多太多了。

社区服务

当一个新的项目刚刚诞生时,在这个项目上能被称作专家的,就只有那些把它写出来的人。他们是仅有的能够撰写文档和解答问题的人,同时,在对软件的改进方面,他们也是最佳人选。

但结果,我们这类TensorFlow团队中的核心成员反倒成为了项目成长的瓶颈。原因其实很简单:我们没法一次性把所有的事情都干完。是,我们确实知道该怎么腾出时间去写代码和文档,因为这本来就是我们在谷歌日常工作的一部分;但要给一个超大社区里的众多开发者解答问题,我们就有点懵比了——尽管我们知道,这对于项目的成功十分重要。

为了确保用户们能够得到他们需要的答案,核心工程团队的全体成员开始轮班。每个人可以从以下几个活里自己挑:处理Stack Overflow上带有#tensorflow标签的问题、检查一遍GitHub上的pull request、给GitHub上的issue分类、同步外部和内部代码,或是找到那些失败测试的原因。

如何分配这些工作由大伙自己决定。一般来讲,如果每个工程师每次在一个特定领域负责一周的话, 我们勉强能让这个轮班机制循环起来。这个机制实行之后,工程师们在他们值班当周的本职工作产出会大大降低——不过至少,每个人的工作被打断的频率降到了几个月一次。

Pull request

我们将TensorFlow开源来让社区能够对其贡献力量。到目前为止,已经有超过400人从外部为我们贡献了代码,这其中既包括简单的文档修复,也包括像OS X的GPU支持、OpenCL的执行、InfiniBand架构下RDMA这样的大输血。首先,每次贡献都会先从轮值核心工程师那里审一遍,以确定其是否真的管用;如果方案通过了最初的审核,我们会对它进行一组Jenkins测试来确保它不会引发任何故障;如果以上两道程序都被通过了,轮值工程师会将方案交给另一位更加擅长相关领域的核心工程师再次进行审核。

在这一过程中,GitHub全新的精细代码审核工具能够为我们提供极大的帮助。而在它出现之前,要把所有人的评价都处理一遍是个十分痛苦的事情。当一名核心工程师与一位或更多的外部贡献者协作时,经常会有更大的pull request会被放入正在进行的工作中。直到每个人都满意之后,PR就会被合并到GitHub上的树顶,并在下一次同步运行时被合并进我们的内部代码库。

代码许可协议

作为自动化pull request程序的一部分,我们会将贡献者的GitHub账号与我们在谷歌开发者网站上的代码许可协议(CLA)记录相匹配,以确保每个外部贡献者都拿到了CLA。我们的目标是是确保整个代码库都在阿帕奇2.0协议下准确无误地得到了分配。当pull request的轮值工程师要对出现的全部问题进行归类的时候,如果一个pull request的内部关联了多个邮箱,或是贡献者需要以团体名义登录,情况就会变得十分麻烦。

GitHub issue

GitHub用户们已经提交了5000多个关于TensorFlow的issue。对于有些人来说,这可能有点让人沮丧;但对我来说,issue却是个最棒的单位——因为它证明,人们是真的在使用这个软件。

为了确保我们回应了每个存档的issue,轮值工程师会时刻查看新出现的信息并试着用标签对其进行分类。如果那是个我们在短期内无法在内部搞定的问题,它就会被标记成“欢迎贡献”;对于一些待处理的bug,我们会给他们按轻重缓急排个次序。这些天来,随着一些外部用户自己变成了某些问题的专家,越来越多的问题没有借助我们的力量就被解决掉了,特别是在像Windows这类我们不会每天都用的平台上。

如果一个issue没能在社区中找到回答或修复,而它的优先级又足够高时,值班的人就会把它分配给团队里一个了解此类问题的工程师。整个TensorFlow团队的成员都有自己的GitHub账号,因此我们可以用正常的GitHub issue追踪器来实现任务的分配。我们确实考虑过把GitHub上提交的bug复制到我们的内部系统中,但要为相同信息同步两份副本,代价太高了。最后,我们让工程师们除了留意内部系统的追踪器之外,也要打开邮件通知,以便能够及时看到自己被分配了哪些GitHub上的问题。

Stack Overflow

Derek Murray是Stack Overflow值班小组的带头大哥,我觉得他回答问题的技能真是碉堡了。根据他的资料页,这个人发过的帖子已经触及到了130万人;为了让我们能够及时追踪网站上那些带有#TensorFlow标签的问题,他还设法创建了一个RSS驱动的自动化电子表格。起初我们采取每周轮班制,但发现要处理问题的量对于一个人来讲实在是太大了;后来我们采用了自动分配系统,情况变得好多了。

我本人就在这个轮班小组里,因此每天早上我浏览完自己的邮件后,我都会查看电子表格来弄清楚自己被分配到了哪些问题。很遗憾,我们没法自己回答全部的问题,但每一个新进来的问题我们都会看。如果问题相对简单的话,我们就自己把它答了。

当然,值班的工程师得顶到被问题轰炸的前线去,但有些时候,回答某些问题需要更多的时间和专业知识。如果某个问题看上去能被答出来,但社区里却没看见站出来的英雄,我们就会研究一下代码,扒一下团队里有谁可能会对这个问题有些想法(通常是用git blame)。然后值班工程师就会向我们找到的人发封邮件,看其是否能提供一点帮助。

邮件列表

我们设置了一个邮件列表,但起初却并不知道该怎么用它。我们很快就看出来,用这种方法来追踪issue和回答一般问题有多辣鸡。

后来,我们把它当成讨论区来用,GitHub和Stackoverflow都不合适的话题,就发到邮件列表,但是在实际操作中我们发现,即便是架构问题,用GitHub issue来讨论也比邮件列表合适。

现在我们用这个邮件列表来发送信息和贴通知,还算是值得订阅的。

代码同步

和我聊过的许多人都对一件事表示十分吃惊——那就是在谷歌内部,我们使用的代码库和我们在GitHub上所开放的几乎完全相同。不过,两者间还是存在一点区别的,比对谷歌专用基础设施的支持是独立的,路径也和GitHub版不一样,但同步的过程是完全机械的。我们至少每周推出一次内部更新,更多时候是下载GitHub版本。

麻烦的是,我们要进行双向同步。在GitHub的公共项目和我们的内部版本上,有很多变动是同时发生的,而我们需要反反复复地把它们全部进行合并。没有现成的基础架构可供利用,因此我们使用了自己创造的一套Python脚本来处理这些问题。这些脚本能够将GitHub上所有的变动拉进我们的内部资源库里,转换所有的header path和其他细微的变化,将它们和最新内部版代码合并,并在内部创建一个副本。随后就可以进行另一个方向的同步了,我们会将所有的内部代码转换成外部的格式,并用相同的脚本把这些结果合并到最新的GitHub版上。

对于内部的修改,我们同样会尽力让每次check-in都呈现为单独的git commit,同时把作者的GitHub账号和解释这些变动的评论包括在内。我们在GitHub上有一个特别的“TensorFlow园丁”账号来完成上述过程,一个内部的commit被转移到GitHub上之后,是这样的:

要确保即使代码变了,这个转换流程依然有效,是很有挑战性的。为了验证这种有效性,我们要求把内部代码通过这个脚本转换成外部版本,再转换回来之后,和最初的内部版一模一样。在任何接触到TensorFlow代码库的内部更改上,我们都会运行这个测试,通不过测试的修改会被拒绝。

对于那些提交pull request的人,我们常常会提一些奇怪的变更要求,通常,这样做的原因是我们必须确保他们的代码能适用于这个同步流程。

Jenkins测试

因为要支持很多不同的平台,我们希望有一个适用范围很广的测试工具。TensorFlow会在Linux、Windows、OS X、iOS、Android、Android Things、以及树莓派上运行,同时我们还有为GPU准备的不同代码路径,包括CUDA和OpenCL支持、以及Bazel、cmake,和无格式makefile的构建进程。

让每一位开发者都在做了变更时手动把上面这些东西全都测试一遍,是不可能的。因此,我们有一套能在绝大部分支持平台上运行的自动化测试系统,这些系统全都处于Jenkins自动化系统的控制之下。始终让它们发挥作用也不是件容易事,因为总会存在操作系统更新、硬件问题以及其他一些与TensorFlow相关的问题能让测试失败。我们有一个工程师团队,专门负责让整个测试系统正常运行,这个团队曾经在系统出问题的时候救过我们很多次。因此在这方面的投入也是值得的。

开发者关系

在开源领域,我们在谷歌并不孤独:我们曾经在Kubernetes和“ 开源计划办公室”(Open Source Program Office)这样的项目上学到过很多东西。有一支非常勤奋的开发者关系专家团队协助我们处理这些事务,他们还承担了很多围绕文档、代码示例以及其他一些开发者经验方面问题而产生的体力活。我们的长期目标是,将关键的专业知识传递到核心开发者之外的范围,以便更多的人能够对社区有所贡献。

让这些核心工程师在部分时间内去承担客户服务工作的一大好处是,它给了我们关于用户所遇到问题的直接洞见。参与客户服务同样驱动着我们去修复那些常见的bug和补充文档,因为它在减少工作量方面让我们看见了直接的回报。

未来,我们希望将这项工作更广泛地进行下去。同时,我们也设计了更多的“战术指导手册”以帮助人们处理常见任务。能有机会同如此多的外部开发者互动,我感觉十分幸运;我也希望,自己能对他们产生积极的影响,帮助他们用机器学习创造新的神奇应用。

关于作者

Pete Warden是TensorFlow Mobile团队技术主管。在加入Google之前,他曾任Jetpac CTO,该公司提供为手机和嵌入式设备而优化的深度学习技术,2014年被Google收购。他还曾在苹果工作,负责图像处理的GPU优化。

原文发布于微信公众号 - 量子位(QbitAI)

原文发表时间:2017-05-07

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏工科狗和生物喵

我的工程师的能力评估和发展

Part 1 虽然是作业,但是我也准备好好地评估一下自己的能力,看看自己到底有多菜鸡,好给自己一个响亮的耳光来督促后面的自我学习!所以我就好好地给自己评估下(参...

31050
来自专栏熊二哥

考试备战系列--软考--01基础架构概念

由于一些知识性的特殊需要,要求掌握比较过时的软件架构设计理论,因而作此文案用于记忆和查询。该部分内容与现实中软件开发相去甚远,也可以理解一些东西之间确实存在很大...

19660
来自专栏敏捷开发&项目管理

敏捷项目需求拆解&发现用户故事

需求文档和敏捷中的Epic,User Story, Task之间是什么关系以及如何将需求文档转换成敏捷方式的描述,指导开发人员。 一直是很多公司团队比较困扰的问...

58960
来自专栏云成本管理

云成本管理方法论(一)——云成本管理模型

由于零固定投资和具有弹性等显著优势,云计算已被绝大多数的企业所采用。但与此同时,由于尚未形成有效的管理实践,云资源的过度使用和浪费已成为云用户关注的最主要问题。

505110
来自专栏FreeBuf

美国数据公司LocalBlox泄露了4800万个人数据记录

又有一个数据泄露成为头条新闻,再次被Upguard的数据泄露猎手发现。美国数据机构LocalBlox在网上暴露了一个不安全的在线AWS库,其中包含部分来自Fac...

9210
来自专栏带你撸出一手好代码

会当凌绝顶,一览众山小,宇宙第一的visual studio诞生20年回顾

IDE华山论剑,天下第一非微软家的visual studio莫属。 visual studio以极佳的用户体验和高效的协助工程师工作而著称, 深得无数开发者喜爱...

301100
来自专栏企鹅号快讯

程序员的核心竞争力是什么?

我们都知道学习能力很重要,那么学习能力从何而来,除了去看书上课这种,如何在实践工作中学习成长? 我之前微博说了一个笼统的概念,什么是能力? 对待问题的态度,以及...

20370
来自专栏木东居士的专栏

使用 PageRank 找到关系网中的牛人

21120
来自专栏Golang语言社区

用医生的思考方式调试你的代码

“现在的编程工作就像是对你需要解决处理的部分做科学研究。” ——Gerald Sussman 设计和维护好的软件就像是一个抵制复杂度的永无止境的奋斗过程。任何足...

36160
来自专栏FreeBuf

键盘敲击识别技术真的靠谱吗?

所有人都知道密码是靠不住的。于是现在有一个有意思的行为生物识别是“你是如何打字的”,或称为输入行为生物识别技术。 生物识别正在广泛推广 大多数网络用户在选择密码...

23150

扫码关注云+社区

领取腾讯云代金券