This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [GCC Steering Committee attention] [PING] [PING] [PING] libgomp: In OpenACC testing, cycle though $offload_targets, and by default only build for the offload target that we're actually going to test


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]