Re: [Gluster-users] [FEEDBACK] Governance of GlusterFS project

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





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. 



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.
 

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=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 

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. 

[Index of Archives]     [Gluster Users]     [Ceph Users]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux