On Thu, Aug 04, 2016 at 09:12:36PM +0100, Manuel López-Ibáñez wrote:
> On 04/08/16 15:49, Thomas Schwinge wrote:
> >I suppose, if I weren't paid for paid for this, I would have run away
> >long ago, and would have looked for another project to contribute to.
> >:-(
>
> You are a *paid* developer for one of the most active companies in
> the GCC community. Imagine how it feels for someone who just
> convinced their company to let them contribute for the first time or
> a volunteer:
>
> https://gcc.gnu.org/ml/gcc/2010-04/msg00667.html
> https://gcc.gnu.org/ml/gcc-patches/2016-08/msg00093.html
>
> They will never bother to send an email like this and just silently
> go away. People do give up and move somewhere else based on this
> problem only. (And nowadays, this decision is quite easy to make or
> sell to one's boss)
>
> >OpenACC/OpenMP/offloading patches. I'm certainly not going in any way to
> >disapprove Jakub's help, skills and experience, but I'm more and more
> >worried about this "bus factor" of one single person
> >(<https://en.wikipedia.org/wiki/Bus_factor>).
>
> This is a problem throughout GCC. We have a single C++ maintainer, a
> single part-time C maintainer, none? for libiberty, no regular
> maintainer for build machinery, and so on and so forth.
I'd object to this being "throughout" GCC. There are a number of very good,
very responsive, very helpful GCC reviewers in our community. However, as
you'd expect, the most active areas for contribution are the most active
areas for review.
> This has been a problem for a very long time, but it seems to be
> getting worse now that fewer contributors are doing most of the
> work.
Rumours of GCC's death have been greatly exagerated!
At times it might feel this way, but the data
(BlackDuck at www.openhub.net and my own analysis on the Git Mirror)
suggests that actually the GCC community is near enough as strong as it
has been for most of the past 20 years, both in terms of volume of
contributions, number of contributors, and average number of contributions
per contributor. Some rudimentary stats gathering on the git mirror suggests
no substantial change in the makeup of the community over the years. If
anything there are more commits from more people and the average number of
commits per committer is decreasing.
GCC releases come over an uneven time period, so I've stuck to years and
statistics for those years. The tables give the number of contributors in
each "bucket" of commits. Note that the earlier years are skewed a little
as Jeff used to do the "Daily bump" that is now done by gccadmin, and
I haven't tried to strip this from the early numbers. As soon as it became
practical to I dropped that from the commit count.
------------------------------------------------------------------
Year | 1998 | 2001 | 2004 | 2007 | 2010 | 2013 | 2015 |
------------------------------------------------------------------
Total Commits | 4996 | 6864 | 9139 | 6632 | 7589 | 5972 | 7742 |
Total Commitors | 44 | 116 | 153 | 167 | 171 | 176 | 190 |
Average commits | 114 | 59 | 60 | 40 | 44 | 34 | 41 |
------------------------------------------------------------------
Number of committers with... |
0-19 commits | 16 | 55 | 71 | 91 | 103 | 110 | 115 |
20-39 commits | 8 | 19 | 26 | 26 | 28 | 28 | 32 |
40-59 commits | 4 | 9 | 10 | 19 | 13 | 16 | 12 |
60-79 commits | 3 | 7 | 10 | 9 | 3 | 4 | 5 |
80-99 commits | 2 | 6 | 10 | 5 | 4 | 4 | 4 |
100+ commits | 11 | 21 | 27 | 18 | 21 | 15 | 23 |
------------------------------------------------------------------
So far for 2016 we're on:
Total commits: 4096
Total Contributors: 152
Average commit count per contributor: 26.9474
0-19 101
20-39 22
40-59 13
60-79 3
80-99 5
100+ 9
We shouldn't let the external perception of the GCC community influence
how we talk about it. Statistics like this are easy enough to generate
from git for any time period you like, and counter most of the prevailing
commentary on the direction and quality of the GCC community.
The script I used to generate the above was nothing special...
RANGE=<git range>
git shortlog -s -n $RANGE | awk '{if ($2 != "gccadmin") {sum+=$1;count+=1};
if ($1 < 20) {bucket1+=1} else if ($1 < 40) {bucket2+=1} else if ($1 < 60)
{bucket3+=1} else if ($1 < 80) {bucket4+=1} else if ($1 < 100) {bucket5+=1}
else {bucket6+=1} } END {print " Total commits: " sum; print " Total
Contributors: " count; print " Average commit count per contributor: " sum /
count; print " 0-19\t" bucket1; print " 20-39\t" bucket2; print "
40-59\t" bucket3; print " 60-79\t" bucket4; print " 80-99\t"
bucket5; print " 100+\t" bucket6}'
> >... if I remember correctly), was that in addition to him, all
> >Global Reviewers are welcome to review OpenACC/OpenMP/offloading patches.
> >But that doesn't help if that's then not happening in reality. (With the
> >exception of Bernd, who then did review such patches for a while, but
> >also seems to have stopped with that again.)
>
> At least half of the global reviewers in MAINTAINERS never review
> any patches. Most of them are not active any more and presumably do
> not read GCC emails.
That's just false.
Richard Earnshaw <richard.earns...@arm.com>
Richard Biener <rguent...@suse.de>
Richard Henderson <r...@redhat.com>
Jakub Jelinek <ja...@redhat.com>
Jeff Law <l...@redhat.com>
Jason Merrill <ja...@redhat.com>
Michael Meissner <g...@the-meissners.org>
Joseph Myers <jos...@codesourcery.com>
Bernd Schmidt <bschm...@redhat.com>
Ian Lance Taylor <i...@airs.com>
Jim Wilson <wil...@tuliptree.org>
I've seen all of these active on the lists during 2016 to a lesser or
greater exentent.
So there are only 3/14 (21%) I haven't seen for a a while...
Geoffrey Keating <geo...@geoffk.org>
Richard Kenner <ken...@nyu.edu>
David S. Miller <da...@redhat.com>
> I'm not sure how to address this problem, but there is definitely a
> problem. Some ideas:
>
> a) Follow LLVM's model and allow changes to be reviewed after commit.
If we were to take anything from LLVM's model it should be the use of a
review tool that makes prioritising patches to review by age easier.
I love email, but it is a stone-age tool for patch review and makes it
very easy for patches to fall through the cracks.
The commit/revert/commit/revert/commit/revert/commit model doesn't look
particularly helpful (though it does help your blackduck numbers I guess)
and *requires* effective continuous integration testing infrastructure across
targets. Only by being able to quickly identify and revert a broken commit
do you remove the pain. Otherwise you've shifted trouble from one person
waiting for a review to N maintainers manually bisecting to find out why
their target has regressed. That's not a good way for any of us reviewers
and maintainers to spend our time.
We're not in a world of good integration testing yet, the best we've got at
the moment is maintainers yelling on IRC when something has gone wrong. We
also support a much wider (and quirkier) range of targets than LLVM. I'd
expect that the effect of this policy would be much more churn over much
longer time periods than the LLVM community manage.
If someone wants to build some good scripts such that we could use to
build continuous integration testing infrastructure, that would probably
be very valuable to the community. Things like robots that repeatedly build
and then bisect bootstrap failures on the Compile Farm machines would be
handy. Better yet if you can automatically pick up testsuite regressions.
> b) Anyone with svn-write powers can approve patches.
At the point where an svn-write user has been contributing meaningful
feedback over a medium-term, I'd hope that the maintainer for that area would
recommend them as a reviewer for that area. I don't having a set of unproven
reviewers is meaningfully different than a) and it suffers from the same
issues.
> c) Everybody have to get their patches reviewed, promote a "Review-by"
> economy.
Seems to solve a problem we don't have.
> d) Delegate hierarchically. Module owners should seek and delegate
> to people with svn-write powers and ask for reviews in exchange of
> reviews.
This is current policy, see the section "Reviewers" section in MAINTAINERS.
Thanks,
James
