Open Source Community workflow Analysis for patch submission

First look at the patch life cycle.


650) this.width=650; "id=" aimg_523234 "src=" http://cupic.img168.net/bbsfile/forum/201201/20/ 212556cyyms6pm2ppq2w24.jpg "class=" Zoom "alt=" 1.jpg "title=" 1.jpg "width="/> "




First of all, if you have an idea, you can discuss it with the community first, enter the RFC (request for commit) stage, and if you go directly to realize your idea, it may be submitted to the community that everyone does not accept, or is different from the requirements of the community, or others are doing this, Repeating yourself is something you should avoid, so it is necessary to discuss your idea with everyone in the community first. Ok! If you agree with your idea through discussion, you can go to hack, of course, you will have some ideas and suggestions, you have to adopt accordingly. Then put the code out in the community, at this time you will discuss your code, some people will criticize, remember not to attack the people who criticized you, should be open-minded to accept, you can say "thanks", and accordingly adopted. Where there is a problem, go to fix the bug, and then submit it again, you can discuss, for green hand, the process of submitting a patch is still difficult, for a person who is more prestigious in the community, we believe him better, patch is more likely to be adopted. After repeated discussion, modification, if your patch is adopted, you can submit to the corresponding maintainer, remember is subsystem maintainer, rather than linus,linus big talent no time bird you, in fact, each maintainer is also very busy. If he sees everyone passing through the community, he's looking at it, and your patch is being adopted. Linus sometimes look at patches in the community, so some people also receive patch replies, remembering that instead of sending patches to Linus, he sees patches in your community and he doesn't have the time to bird you. Andrew Morton is a maintainer of mm tree, and this tree includes some mm-related and others that do not belong to any subsystem tree, and are sent here, in one of the other subsytem tree maintainer.


650) this.width=650; "id=" aimg_523235 "src=" http://cupic.img168.net/bbsfile/forum/201201/20/ 212557i5642pbvqz1m95qp.jpg "class=" Zoom "alt=" 2.jpg "title=" 2.jpg "width="/> "

You can submit some feature to maintainer, if passed, maintainer will feature in the Merge window to the Linus, after each release of a version will have a merge window, about one Weeks,linus will accept maintainer submitted by the new features, after two weeks, the merge window closed, do not receive new features, this time maintainer can wait until the next merge The new feature can only be submitted when the window arrives. Next is-RC1~-RCN, about to end in-rc6~-rc9, if Linus feel that has been stable the end, each-RC about a week,-RCN after the release of the next version. -RC1~-RCN between the main bugfix, you are obligated to fix your feature, others will fix your feature, if you do not fix, your feature may be pass off.

This article is from the "ganshizhe.bokee.com" blog, make sure to keep this source http://328538.blog.51cto.com/318538/1725771

Open Source Community workflow Analysis for patch submission