0
点赞
收藏
分享

微信扫一扫

记录一次简单的PR过程(修补代码可读性)

OpenCV使用了两步PR审核。当开发者提交pull request后,PR首先需要通过OpenCV Buildbot的自动测试,包括18种测试配置。


当PR通过了自动测试后,OpenCV核心团队的成员将会对PR进行审核,若通过则此PR将会被集成进OpenCV主版本中。



记录一次简单的PR过程(修补代码可读性)_OpenCV


最近在翻看OpenCV的代码的时候,发现blobdetector.cpp下 有两行注释比较碍眼,应该是明显的错误:



记录一次简单的PR过程(修补代码可读性)_OpenCV_02

​​


由于OpenCV始终维护稳定的master,因此我们需要建议分支,分支可能为bug分支,或者为feature分支。



记录一次简单的PR过程(修补代码可读性)_自动测试_03



这个操作可以直接在网站上完成,首先是将自己的版本更新到最新,而后建立分支



记录一次简单的PR过程(修补代码可读性)_OpenCV_04


注意我一般是用branch为3.4(很久之前是推荐这样的,但是现在我也有看到直接pr到master中的)



记录一次简单的PR过程(修补代码可读性)_OpenCV_05

​​



在新建的分支中修改代码,并且保存,而其后在OpenCV中选择“Pull requests”



记录一次简单的PR过程(修补代码可读性)_OpenCV_06

​​


其中画线的几个地方是特别需要注意到



记录一次简单的PR过程(修补代码可读性)_自动测试_07

​​


稍微等一下,出现这个黄圈,表示正在进行buildbot



记录一次简单的PR过程(修补代码可读性)_自动测试_08

​​



记录一次简单的PR过程(修补代码可读性)_OpenCV_09

​​


内部替用户实现了不同平台上的加速代码。



记录一次简单的PR过程(修补代码可读性)_自动测试_10

​​




全部成功后,进入review阶段(也可能不成功,也有人给你提意见)。较为简单的注释删除、bug修改通过的概率比较大;困难一点的是提交例子或者教程;最为复杂的是提交函数,需要你提供文档和Test。


当reviewer关注到你的问题后,他们会给你提出很专业的建议,并且提供相关文档资料,应该说是非常正规的。比如这里:



记录一次简单的PR过程(修补代码可读性)_OpenCV_11

​​


asmorkalov(来自intel)将我这个pr添加了photo的标签,并且委派给mshabunin(估计他是负责这个部分的),而后就会看到这个


记录一次简单的PR过程(修补代码可读性)_开发者_12


相关的修改就会被及时关注。当然如果别人提出的合理要求你老是不修改,也会被close.


最后,这个PR并没有被通过,理由是过于琐碎;但是有一个类似的PR在经过长时间的无人问津之后被Merged



记录一次简单的PR过程(修补代码可读性)_开发者_13

​​


两者都是类似的。应该说我观察到OpenCV的PR机制由于有Intel在其中作用,总的来说还是比较成熟的:只要是言之有物的PR,最终就一定会被吸收进去。


感谢阅读至此,希望有所帮助。





举报

相关推荐

0 条评论