On 04/06/2025 14:57, David Edelsohn wrote:
On Wed, Jun 4, 2025 at 5:24 AM Richard Earnshaw (lists)
<richard.earns...@arm.com <mailto:richard.earns...@arm.com>> wrote:
On 03/06/2025 20:41, David Edelsohn via Gcc wrote:
> On Tue, Jun 3, 2025 at 3:23 PM Richard Sandiford
<richard.sandif...@arm.com <mailto:richard.sandif...@arm.com>>
> wrote:
>
>> David Edelsohn <dje....@gmail.com <mailto:dje....@gmail.com>>
writes:
>>> On Tue, Jun 3, 2025 at 6:22 AM Richard Sandiford via Gcc <
>> gcc@gcc.gnu.org <mailto:gcc@gcc.gnu.org>>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> At the moment, all reviewers and maintainers have to be
appointed by the
>>>> Steering Committee. I wonder if we could add a second, more
>>>> community-based
>>>> route: someone can be appointed as a reviewer or maintainer
with the
>>>> agreement
>>>> of a given number of people who already have an equal or
greater remit.
>>>>
>>>> It's already possible for reviewers or maintainers to defer to the
>>>> opinion of someone they trust and rubber-stamp that other person's
>>>> review or patch. Having the ability to appoint the other
person as a
>>>> co-reviewer or co-maintainer of that area is really just replacing
>>>> patch-by-patch trust with a more ongoing trust.
>>>>
>>>> If that seems a bit woolly, and if a more formally defined process
>>>> seems necessary, then how about this strawman:
>>>>
>>>> * Someone can be nominated to be a reviewer of an area by
sending a
>>>> private email to every reviewer and maintainer who covers a
non-strict
>>>> superset of that area. The nomination is approved if it is
supported
>>>> by at least two such reviewers or maintainers and if there
are no
>>>> objections. People would be given at least a week to respond.
>>>>
>>>> * The process would be the same for maintainers, with the same
set of
>>>> addressees, except that there must already be at least one
maintainer
>>>> for that area and, in addition to the previous requirements,
all such
>>>> maintainers must be in favour.
>>>>
>>>> (So if the area is maintained by one person, the nomination
would
>>>> need the support of that maintainer and at least one
reviewer of a
>>>> wider area. If the area is maintained by two of more
people, they
>>>> would all need to agree.)
>>>>
>>>> The idea with making it private is that it allows for a more
honest
>>>> discussion. But the convention could be to have a public
discussion
>>>> instead, if that seems better.
>>>>
>>>> Like I say, this would just be a second, alternative route.
It would
>>>> still be possible to ask the SC instead.
>>>>
>>>> In case it sounds otherwise, I'm really not trying to pick a
fight here.
>>>> I just don't remember this being discussed on-list for a long
time,
>>>> so it seemed worth bringing up. (Maybe it has been discussed
at the
>>>> Cauldron -- not sure.)
>>>>
>>>
>>> What is a request to the GCC SC preventing?
>>>
>>> The GCC SC already requests the opinion of existing reviewers and
>>> maintainers.
>>
>> Like I say, the idea isn't to replace the existing system, just to
>> provide a second, alternative path.
>>
>> But I suppose the question works both ways: does the SC need to be
>> involved in every decision? There doesn't seem to be a specific
need
>> for the SC to act as the gatherer of opinions if the
maintainers/reviewers
>> are able to agree on a candidate directly amongst themselves.
In cases
>> like those, having the conversation directly would be a lighter-
weight
>> and more transparent process (especially if, as Richard suggests,
>> the discussion happens in public).
>>
>
> What is not working with the current system? What is this fixing?
>
There is no formal way of requesting/tracking requests sent to the
SC. It relies on sending private mail to individuals since the SC
lacks a formal contact email. Frequently those meet with no
response or need to be repeatedly sent/pinged. There's also little
transparency as to the progress of requests - you fire something off
to a black hole and hope that some day it might be fired back out
with a suitable response.
Where can we see a list of issues the SC is considering. Where is
the record of any resolutions to requests? I think it's fine for
the discussions to be private, but there really needs to be more
transparency as to what topics are being covered and what the
resolutions are.
> The GCC SC has not been notified of any problems with appointing
> maintainers.
Then consider this to be a notification. I know that it can take
months for reviewers to be appointed, let alone maintainers.
I brought a couple of issues up at the cauldron last year, but I see
no sign that there's been any progress on them. Transparency of the
SC is an issue at present.
R.
The GCC Steering Committee members are listed on the web site and
contact information for most, if not all, is listed in the MAINTAINERS file.
So every request should be emailed to every SC member? If not, how
should the SC be contacted?
An email distribution list to contact the GCC SCC introduces the
ambiguity of who is "on duty" to respond.
How that's managed is really up to the SC though. At present, it's just
not working, sorry.
The GNU Toolchain now holds monthly office hours, at which GCC SC
members frequently attend, and no issues were raised during those meetings.
I'm well aware of the meeting, I've attended several. But I wasn't
aware that this was now the way we raise issues with the SC, since the
meeting is cross-component.
When a GCC SC request has come to me, I have made every effort to handle
it in a timely manner. In some sense, I had been acting as the
unofficial GCC SC Secretary, but apparently that created friction.
I am not aware of any current requests for appointment of maintainers,
at least not the appointment of people who wish to be / have agreed to
additional responsibility.
I don't know whether or not there are any right now, since there is
nowhere I can look.
I did raise the issue of SC transparency during the Q&A session at the
2024 cauldron; I'm aware that you were unable to attend last year, but
there were other members of the SC present.
I was going to point you to the youtube video of the session, but it
appears to be missing :( I don't know if that's due to a technical
glitch or some other problem, or if the session simply wasn't recorded.
R.
Cheers, David
>
> Thanks, David
>
>
>>
>> Thanks,
>> Richard
>>
