[Gluster-devel] [Gluster-users] [FEEDBACK] Governance of GlusterFS project

[Harshavardhana]

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

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.

Combining the meritocratic system + a ultimate decision makers (dispute
resolution)

1. Her activity among the community
2. Quality and Nature of her contributions
3. Module Owners
4. Super Reviewers
5. Release drivers
6. Component owners (Bugzilla)
7. Former module owners (Acknowledge their contribution from the past) -
Example Vikas, Shehjar etc
8. Ultimate Decision Makers - a total of 2 for the whole project

-- 
*Religious confuse piety with mere ritual, the virtuous confuse regulation
with outcomes.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-devel/attachments/20130727/36162367/attachment-0001.html>