<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>- Be responsible for maintaining release branch.</div><div>- Deciding branch points in master for release branches.</div><div>- Actively scan commits happening in master and cherry-pick those which improve stability of a release branch.</div>
<div>- Handling commits in the release branch.</div><div>- Deciding what outstanding bugs must be fixed for a release.</div><div>- Backporting (with the help of the original author for patches which require rebase/conflict resolution) patches to release branches.</div>
<div>- Deciding on stability of a point in the release branch and making the release off it.</div><div><br></div><div><br></div></div></div></div></blockquote><div><br></div><div>There are many different models some of which are time tested which have worked for more than a decade and at a scale of 100,000's of patches millions of lines of code. </div>
<div><br></div><div>1. Linux kernel - <a href="http://www.oss-watch.ac.uk/resources/benevolentdictatorgovernancemodel">http://www.oss-watch.ac.uk/resources/benevolentdictatorgovernancemodel</a></div><div>2. Mozilla Foundation - <a href="http://www.mozilla.org/en-US/about/governance/">http://www.mozilla.org/en-US/about/governance/</a></div>
<div>3. Openstack - <a href="https://wiki.openstack.org/wiki/Governance">https://wiki.openstack.org/wiki/Governance</a></div><div><br></div><div>If you see the 'bylaws' of these projects it choose 'meritocracy', 'direct democratic' models. </div>
<div><br></div><div>What is good for GlusterFS as a whole is highly debatable - since there are no module owners/subsystem maintainers as of yet at-least on paper. But i would generally think Mozilla style and Openstack style works. BDFL model is old school but works.</div>
<div><br></div><div>This seems to me might be necessary to do what this email is about as the project moves into 3.4.0 --> 3.5.0 and further.</div><div><br></div><div>Here is the run down of why it is necessary `sloccount`</div>
<div><br></div><div><div>SLOC Directory SLOC-by-Language (Sorted)</div><div>-----------------------------------------------------------------------------------</div><div>185897 xlators ansic=183597,python=1807,sh=493</div>
<div>27998 libglusterfs ansic=27448,yacc=481,lex=69</div><div>23317 rpc ansic=23317</div><div>14719 cli ansic=14719</div><div>10330 top_dir sh=10289,python=41</div>
<div>6562 contrib ansic=4783,python=1769,sh=10</div><div>6486 doc xml=6486</div><div>5707 tests sh=5021,ansic=477,python=209</div><div>5633 extras ansic=2749,sh=1599,python=1161,lisp=124</div>
<div>4718 argp-standalone ansic=3672,sh=1046</div><div>4699 api ansic=4369,python=327,sh=3</div><div>3499 glusterfsd ansic=3499</div><div>2702 geo-replication python=2316,ansic=386</div>
<div>1196 glusterfs-hadoop java=988,python=144,xml=64</div><div><br></div><div>Totals grouped by language (dominant language first):</div><div>------------------------------------------------------------------------------</div>
<div>ansic: 269016 (88.65%)</div><div>sh: 18461 (6.08%)</div><div>python: 7774 (2.56%)</div><div>xml: 6550 (2.16%)</div><div>java: 988 (0.33%)</div><div>yacc: 481 (0.16%)</div>
<div>lisp: 124 (0.04%)</div><div>lex: 69 (0.02%)</div></div><div><br></div><div><div>Total Physical Source Lines of Code (SLOC) = 303,463 </div><div>Development Effort Estimate, Person-Years (Person-Months) = 80.77 (969.22)</div>
<div> (Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05))</div><div>Schedule Estimate, Years (Months) = 2.84 (34.10)</div><div> (Basic COCOMO model, Months = 2.5 * (person-months**0.38))</div>
<div>Estimated Average Number of Developers (Effort/Schedule) = 28.42</div><div>Total Estimated Cost to Develop = $ 10,910,701</div><div> (average salary = $56,286/year, overhead = 2.40).</div>
</div><div><br></div><div>If we choose Meritocratic Polling scheme this is how the eventual breakdown looks like</div><div><br></div><div><a href="https://github.com/gluster/glusterfs/contributors">https://github.com/gluster/glusterfs/contributors</a> - Look at the top #50 contributors list. <br>
</div><div><br></div><div>Combining the meritocratic system + a ultimate decision makers (dispute resolution)</div><div><br></div><div>1. Her activity among the community</div><div>2. Quality and Nature of her contributions</div>
<div>3. Module Owners</div><div>4. Super Reviewers</div><div>5. Release drivers</div><div>6. Component owners (Bugzilla)</div><div>7. Former module owners (Acknowledge their contribution from the past) - Example Vikas, Shehjar etc</div>
<div>8. Ultimate Decision Makers - a total of 2 for the whole project</div><div><br></div><div>-- </div><div><div dir="ltr"><i>Religious confuse piety with mere ritual, the virtuous confuse regulation with outcomes.</i></div>
</div><div><br></div></div></div></div>