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/benevolentdictatorgovernancemodel2. Mozilla Foundation - http://www.mozilla.org/en-US/about/governance/3. Openstack - https://wiki.openstack.org/wiki/GovernanceEach 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.
Agreed
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=49327998 libglusterfs ansic=27448,yacc=481,lex=6923317 rpc ansic=2331714719 cli ansic=1471910330 top_dir sh=10289,python=416562 contrib ansic=4783,python=1769,sh=106486 doc xml=64865707 tests sh=5021,ansic=477,python=2095633 extras ansic=2749,sh=1599,python=1161,lisp=1244718 argp-standalone ansic=3672,sh=10464699 api ansic=4369,python=327,sh=33499 glusterfsd ansic=34992702 geo-replication python=2316,ansic=3861196 glusterfs-hadoop java=988,python=144,xml=64Totals 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,463Development 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.42Total 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 likehttps://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
Github link was meant to be as an example for a possible approach - in any case rudimentary graphs can be constructed locally and there are tools available for that without having github account.
Anything would be interesting and necessary at this point to come up with.
