This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Richard Sandiford appointed RTL maintainer
- From: Gerald Pfeifer <gerald at pfeifer dot com>
- To: Diego Novillo <dnovillo at google dot com>
- Cc: Vladimir Makarov <vmakarov at redhat dot com>, Richard Guenther <richard dot guenther at gmail dot com>, Bernd Schmidt <bernds at codesourcery dot com>, gcc at gcc dot gnu dot org, Richard Sandiford <rdsandiford at googlemail dot com>, Eric Botcazou <ebotcazou at libertysurf dot fr>
- Date: Mon, 18 Jul 2011 01:01:32 +0200 (CEST)
- Subject: Re: Richard Sandiford appointed RTL maintainer
- References: <alpine.LNX.2.00.1106280033320.15592@gerinyyl.fvgr> <4E09C9C0.8090301@redhat.com> <BANLkTikLhBh89mxcL8Dj7i3YHiT=EDabmA@mail.gmail.com> <4E09CD66.9010302@codesourcery.com> <BANLkTikJXXRJ4vo8BHDPfDdx6P4TpapyFw@mail.gmail.com> <4E09D0EC.4030300@redhat.com> <4E09D3EA.9070304@google.com>
On Tue, 28 Jun 2011, Diego Novillo wrote:
>> * ambiguity of the decision. What does RTL optimizers/RTL maintainer mean?
> Anything related to RTL, in my view. As much as possible, I would lean
> towards flexible definitions of maintenance boundaries. If we make them
> too inflexible, this will not help reviews (many patches cross some
> boundary in trivial ways).
>
> We should trust maintainers/reviewers to know their own boundaries and
> decide whether a patch touches too many areas they don't feel
> comfortable reviewing. This has happened many times in the past, with
> no negative consequences. So, reviewers are by and large DTRT.
I agree, and note that this was not a new area being introduced, but
one that existed as such for a while. To reemphasize the point, I know
projects where there is just one status that allows for committing to
the tree(s) and every committer is assumed to use good judgement on
what to commit/approve and when to defer. And like Diego I feel where
applicable (global reviewers, broader areas,...) this has been working
out well for GCC.
>> * appointments are technical decisions and it should be not in
>> jurisdiction of SC.
For the record, while I can understand everything else written here, I
personally disagree with the statement that appointments are technical
decisions only. As we have seen over time (more so in other projects
than GCC, luckily) there is a huge, huge non-technical component to that.
> So, according to what we discussed in London, the SC will essentially
> not make appointment decisions. We will recommend them, and they will
> agree. If we find unreasonable resistance, we will then see what to do
> about that.
The question, I guess, is who "we" is. Though, practically, what you
describe and what has been happening more or less for years is pretty
much the same. :-)
Gerald