On Sat, Jul 27, 2013 at 12:40 PM, Harshavardhana <harsha at harshavardhana.net>wrote: > > > >> - Be responsible for maintaining release branch. >> - Deciding branch points in master for release branches. >> - Actively scan commits happening in master and cherry-pick those which >> improve stability of a release branch. >> - Handling commits in the release branch. >> - Deciding what outstanding bugs must be fixed for a release. >> - Backporting (with the help of the original author for patches which >> require rebase/conflict resolution) patches to release branches. >> - Deciding on stability of a point in the release branch and making the >> release off it. >> >> >> > 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. > > 1. Linux kernel - > http://www.oss-watch.ac.uk/resources/benevolentdictatorgovernancemodel > 2. Mozilla Foundation - http://www.mozilla.org/en-US/about/governance/ > 3. Openstack - https://wiki.openstack.org/wiki/Governance > > Each of them is interesting in itself. There are certainly concepts we can pick from all. Forming the right roles and responsibilities which will probably be the bulk of this exercise. > If you see the 'bylaws' of these projects it choose 'meritocracy', 'direct > democratic' models. > > 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. > > 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. > > Here is the run down of why it is necessary `sloccount` > > SLOC Directory SLOC-by-Language (Sorted) > > ----------------------------------------------------------------------------------- > 185897 xlators ansic=183597,python=1807,sh=493 > 27998 libglusterfs ansic=27448,yacc=481,lex=69 > 23317 rpc ansic=23317 > 14719 cli ansic=14719 > 10330 top_dir sh=10289,python=41 > 6562 contrib ansic=4783,python=1769,sh=10 > 6486 doc xml=6486 > 5707 tests sh=5021,ansic=477,python=209 > 5633 extras ansic=2749,sh=1599,python=1161,lisp=124 > 4718 argp-standalone ansic=3672,sh=1046 > 4699 api ansic=4369,python=327,sh=3 > 3499 glusterfsd ansic=3499 > 2702 geo-replication python=2316,ansic=386 > 1196 glusterfs-hadoop java=988,python=144,xml=64 > > Totals grouped by language (dominant language first): > > ------------------------------------------------------------------------------ > ansic: 269016 (88.65%) > sh: 18461 (6.08%) > python: 7774 (2.56%) > xml: 6550 (2.16%) > java: 988 (0.33%) > yacc: 481 (0.16%) > lisp: 124 (0.04%) > lex: 69 (0.02%) > > Total Physical Source Lines of Code (SLOC) = > 303,463 > Development Effort Estimate, Person-Years (Person-Months) = 80.77 > (969.22) > (Basic COCOMO model, Person-Months = 2.4 > * (KSLOC**1.05)) > Schedule Estimate, Years (Months) > = 2.84 (34.10) > (Basic COCOMO model, Months = > 2.5 * (person-months**0.38)) > Estimated Average Number of Developers (Effort/Schedule) = 28.42 > Total Estimated Cost to Develop > = $ 10,910,701 > (average salary = $56,286/year, overhead = 2.40). > > If we choose Meritocratic Polling scheme this is how the eventual > breakdown looks like > > https://github.com/gluster/glusterfs/contributors - Look at the top #50 > contributors list. > Meritocracy may be the preferred model (would love to hear from others). GitHub contributor tracking may not necessarily be accurate for us - there is a historic.git on which GitHub does not give out statistics, and more importantly not all our developers have GitHub accounts for it to even count their patches (e.g I don't see Pranith on the list). But yeah, getting the stats is just a matter of tooling. Avati -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://supercolony.gluster.org/pipermail/gluster-users/attachments/20130728/86f65cd0/attachment.html>
