Doesn't the IPMC (and not any individuals, even Roy) decide what the
official Incubation policies should be? Ralph's reply, and my general
reading of the feeling in the IPMC is that graduation votes *should*
take affiliation diversity into account.
Note that some could argue Flume technically meets the diversity
criteria, however I really like Jukka's analysis of who's actually
making the commits - which means they may not necessarily meet the
diversity criteria in spirit yet.
- Shane
P.S. For our public readers, note that Roy's emails are always worth
reading.
On 2012-05-27 5:17 AM, Ralph Goers wrote:
Roy, What you are saying directly contradicts
http://incubator.apache.org/guides/graduation.html#community,
especially the statement "Basically this means that when a project
mostly consists of contributors from one company, this is a sign of
not being diverse enough". Now, if that page is wrong and diversity
is not a requirement for graduation then, of course, that would
certainly remove any objections I have for Flume's graduation.
However, I've heard it said that the ASF does not want to simply
provide the infrastructure for companies to host their products on.
Ralph
On May 27, 2012, at 1:35 AM, Roy T. Fielding wrote:
There is no diversity requirement for graduating from the
incubator. In many ways, incubation hinders community growth. The
requirement is that the project makes decisions as an Apache
project, not in private, which is harder to get used to doing if a
lot of people share the same office.
Diversity is only a warning sign that means we need to check for
decisions made in our forums and advise accordingly. It is not an
end in itself, nor has lack of diversity hindered other projects
from continuing on to build a larger community as a TLP.
....Roy
On May 26, 2012, at 11:44 PM, Ralph
Goers<ralph.go...@dslextreme.com> wrote:
On May 26, 2012, at 9:29 PM, Arvind Prabhakar wrote:
Hi Jukka,
On Sat, May 26, 2012 at 4:43 PM, Jukka
Zitting<jukka.zitt...@gmail.com>wrote:
IIUC Flume operates under an RTC model where people are not
supposed to commit their own changes, which obviously makes
the above data less relevant for evaluating the true
diversity of the community. However, seeing only a single
trivial commit by both jarcec and juhanic even though they
became committers already over three months ago does seem to
suggest that they may not be as comfortable in their
committer role as people from Cloudera are.
As you noted in your comments above - the Flume project tends
to follow RTC with the reviewer committing the code. I happen
to have taken up the role of the reviewer for the most part and
hence you see the skewed commit counts. If you want to see the
actual contribution, I would suggest looking at fixed JIRA
issues by assignees. A quick report yields the following:
aprabhkar - 26 - Cloudera [6] brocknoland - 19 - Cloudera [7]
esammer - 56 - Cloudera [8] hshreedharan - 34 - Cloudera [9]
jarcec - 6 - AVG Technologies [10] jmhsieh - 8 - Cloudera [11]
juhanic - 9 - CyberAgent [12] mpercy - 34 - Cloudera [13]
m...@apache.org - 1 - Trend Micro [14] prasadm - 34 - Cloudera
[15] t...@cloudera.com - 3 - Cloudera [16] w...@cloudera.com - 3
- Cloudera [17]
Looking at this, the average number of issues resolved by
Cloudera committers (not counting Tom who is a mentor) is 26,
and that for non-Cloudera committers is 5. Note that this
number does not include other committer work such as the number
of code reviews they have done, the number of design
discussions they have participated in, something that is very
valuable to the project.
Another way of looking at these same statistics: Cloudera - 217
Other - 16
That means Cloudera is responsible for over 93% of the Jira
issues. It is great that Cloudera is doing so much work but
those stats hardly prove diversity.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail:
general-h...@incubator.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
