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.
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.
Note that it has been more than one year now that just Clang has more monthly
contributors than the whole GCC project:
https://www.openhub.net/p/_compare?project_0=GNU+Compiler+Collection&project_1=LLVM%2FClang+C+family+frontend&project_2=The+LLVM+Compiler+Infrastructure
... 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.
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.
Advantages: Faster turnaround, less frustration. No more effort than now,
possibly less by not requiring pinging. etc.
Disadvantages: code may go unreviewed; churn in the tree because of iterative
changes or reverts.
b) Anyone with svn-write powers can approve patches.
Advantages: More reviewers, faster turn around, less frustration. Distribute
the work.
Disadvantages: Poor patches may get accepted interfering with the work from the
most-active contributors. There is no real incentive to review patches, thus
the actual situation may not change significantly.
c) Everybody have to get their patches reviewed, promote a "Review-by" economy.
Advantages: Actively encourage people to review each other patches. Distribute
effort. Ideally, faster turn-around and less frustration.
Disadvantages: It may slow down people that were able to self-approve.
Additional work for people that contribute a lot in finding reviews. People
that contribute little have little motivation to review.
d) Delegate hierarchically. Module owners should seek and delegate to people
with svn-write powers and ask for reviews in exchange of reviews.
Advantages: No loss in quality, distribute work, creates an economy of reviews.
Disadvantages: More work required from module owners to keep track of patches,
reviews and possible reviewers. Possibly offset by not having to do in-depth
reviews themselves.
Cheers,
Manuel.
