This is the mail archive of the
mailing list for the GCC project.
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
- From: Janne Blomqvist <blomqvist dot janne at gmail dot com>
- To: Manuel López-Ibáñez <lopezibanez at gmail dot com>
- Cc: Thomas Schwinge <thomas at codesourcery dot com>, Jakub Jelinek <jakub at redhat dot com>, gcc mailing list <gcc at gcc dot gnu dot org>, David Edelsohn <edelsohn at gnu dot org>
- Date: Fri, 5 Aug 2016 14:16:42 +0300
- Subject: 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
- Authentication-results: sourceware.org; auth=none
- References: <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org>
On Thu, Aug 4, 2016 at 11:12 PM, Manuel López-Ibáñez
> 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
> 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"
> 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
> 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
The 2-week rule, in particular, came about due to frustration with
lack of reviews.