This is the mail archive of the 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 Thu, Aug 4, 2016 at 11:12 PM, Manuel López-Ibáñez
<> wrote:
> 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.

For the fortran frontend and runtime library, we have a sort-of hybrid
between your options a, b, and c. Namely,

- most of the people who are (or at some point, were) actively working
on the frontend/library have reviewer status (or whatever the title is
in MAINTAINERS). I.e. like your option b) and c).

- The actual maintainers are not really involved in any day-to-day
work anymore (not to disparage their past contributions, which we're
of course grateful for). Just to point out that we're not dependent on
maintainers with super-powers.

- a "2-week rule"; if a patch by a reviewer goes unreviewed for 2
weeks, the reviewer can commit it without review. A bit like your
option a).

The 2-week rule, in particular, came about due to frustration with
lack of reviews.

Janne Blomqvist

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