开源社区工作流程分析

winston

  Open Source Community Work Flow
作者  李万鹏

今天Ram为我们讲解了开源社区的工作流程，其中我感觉比较重要的应该是patch的生命周期和kernel的发布周期。


首先来看patch的生命周期。



首先是如果你有一个idea，你可以先在社区里与大家讨论，进入RFC(request for commit)阶段，如果直接就去实现自己的idea，可能提交到社区大家并不接受，或着与社区的要求不一样，或者别人也在做这个，自己做重复了，都是应该避免的，所以先在社区里与大家讨论你的idea是必要的。OK！如果大家通过讨论同意了你的idea，你就可以去hack了，当然了，大家会对idea提出一些意见和建议，你要相应的进行采纳。然后把代码贴出来在社区里，此时大家会对你的code进行讨论，一些人会提出批评意见，记住千万不要去攻击对你提出批评意见的人，应该虚心接受，you can say “thanks”，并相应的进行采纳。


哪里出现问题，就去fix bug，然后再提交上来，大家再讨论，对于green hand来说，提交一个patch的过程还是比较困难的，对于一个在社区里比较有声望的人，大家更相信他，patch更容易被采纳。经过反复的讨论，修改，如果你的patch被采纳了，你可以提交给相应的maintainer，记住是subsystem maintainer，而不是linus，linus大人才没时间鸟你呢，其实每个maintainer也很忙的。如过他看在社区里大家通过了，他自己在看看，你的patch就被采纳了。linus有时也会看看社区里的patch，所以一些人也收到了patch回复的邮件，记住不是把patch发给linus，而是他看到了你在社区中的patch，他才没那个时间鸟你呢。Andrew Morton是mm tree的维护者，这个tree包括了一些mm相关的还有其他不属于任何subsystem tree的，都被发到这里来，在一个就是其他的subsytem tree maintainer了。



你可以提交一些feature给maintainer，如果通过了，maintainer会将相应的feature在merge window的时候提交给linus，每发布一个版本之后会有一个merge window，大约two weeks，linus会接受maintainer提交过来的new features，过了两周，merge window关闭，不接收new features，此时maintainer只能等到下一个merge window到来的时候才可以提交new feature。接下来就是-rc1~-rcN,大约会在-rc6~-rc9结束，如果linus觉得已经stable了就结束，每个-rc大约一周，-rcN结束后就发布下一个版本。-rc1~-rcN之间主要进行bugfix，你有义务fix 你的feature，别人也会fix你的feature，如果你自己不fix，你的feature有可能被pass掉。


作者：woshixingaaa 发表于2012-1-19 23:40:19 原文链接