5.确定第一个改进方案

英英带着几套方案来找老刘和晓川讨论。方案一是，晓川收到提交后，先在其任务分支上进行构建，没有问题了，再把改动合并到集成分支。老刘提醒，这样晓川要额外费很多时间在任务分支的构建上，因此总的集成时间可能反而会延长。英英问，那能不能让别人代替晓川进行这样的检查。老刘说，可以考虑，先往下看看其他的方案。

方案二是，在提交前，由晓川检查，程序员是否进行了构建并且通过了构建。晓川说，在技术上，这很难查。无法保证程序员向晓川出示的构建结果，就是其任务分支末端的代码编译出来的。事实上，之所以程序员提交了会构建失败的代码，多半是在构建成功后，又改了些内容，以为肯定没问题了，所以没有重新构建就提交了。

方案三是，由程序员所在开发组的领导提交。也就是说，程序员先给领导发信，领导核实后，再给晓川转发。没等晓川说他觉得让领导们给他写信不太合适，英英自己就把这个方案否决了，因为既然方案之二晓川很难查，那方案之三领导也很难查。

方案四是，程序员在申请提交的信里写上“已通过构建”五个字，否则晓川不集成这个提交，打回去重新提交。老刘问，如果程序员说是构建通过了，其实构建没通过，那怎么办？英英说，如果晓川事后分析出这样的事情，她就负责通报批评。

接下来，在项目例会上，英英跟各个小组的领导们重点介绍了第四个方案，大家觉得尽管这个方案不完美，但是相对来说是比较好的，于是讨论通过了这个方案。

会后，英英写了封信给项目全体成员，详细说明了情况，并强调了如果出现了言行不一的情况，要通报批评。信的落款是英英和晓川。

执行的情况是这样的。在下一轮集成里，有两三成的提交没有标明“已通过构建”。晓川逐个给相应的程序员打电话，让他们在保证构建通过后，重新写提交申请。经这么一折腾，星期一晚上到11点才完成了所有提交的合并。那些不得不重新写提交申请的程序员，成了加班到最后的程序员。晓川也有点累。不过这是值得的。因为在周四中午，而不是周末加班，这一版基线就出来了。