From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) by sourceware.org (Postfix) with ESMTPS id 4318A3857817 for ; Tue, 6 Apr 2021 17:17:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 4318A3857817 Received: by mail-lf1-x133.google.com with SMTP id j18so159928lfg.5 for ; Tue, 06 Apr 2021 10:17:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=U1QkIMvpwwtKRYI/ssQEa1y7x7n6z7xbOuELX0v9dfg=; b=bfXMxJljWQuRvXmCBMGMh++YLHPSDACtJNipDeFOgRVl9G/wBvJjm2HYBph/m+R4YN kmuI9fFt9wU36jg0/diIq8ldZlgIax+GlwYQgm5qblo/3Z1TYD+5+jgzydL4peVw4XZs XrMnlKXzG4wmTpQoRi7juE2a3oeHB+ndhnx4E/EhdRBiQBvxh5nBEvNwhoxFc2GrgiNF FOFGoRPzfyQeQHG9OhBY3x7DZsKixe/N5FiscQWqe9uemCzTKnubbCdPw6auJ64lDkIS 18OzyBRBIZ2uivr7nkkGIPItYKyrttcfBWCtnc8O31hJUGXB4VAKSa8GwLHym5SLWhNN X0vg== X-Gm-Message-State: AOAM530zh9hQZpLtPhYyigm+wtHNgGvDlqLUS/w/MTGYxMjZTt5eANXJ ZL0HfX/0n97NFCbizdLG+a0yvsujrBAoDrlANexRBg== X-Google-Smtp-Source: ABdhPJyNtezGx1Q2JlSFRrEcpmF1fxjjn+EF6WWsOOGBSPPOkkDWE/2Q9f+y/1crA2B519YCFqIjZadtWyzvzzI+b9A= X-Received: by 2002:a05:6512:3327:: with SMTP id l7mr22099199lfe.639.1617729451631; Tue, 06 Apr 2021 10:17:31 -0700 (PDT) MIME-Version: 1.0 References: <20210330151656.00007e20@tesio.it> <20210330232849.00001697@tesio.it> <20210331113417.GU2685@wildebeest.org> <3746d7d0-cc06-fc28-eb43-b06a6b577d2b@acm.org> In-Reply-To: From: Ian Lance Taylor Date: Tue, 6 Apr 2021 10:17:20 -0700 Message-ID: Subject: Re: Remove RMS from the GCC Steering Committee To: Richard Biener Cc: Nathan Sidwell , GCC Development Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-17.5 required=5.0 tests=BAYES_00, DKIMWL_WL_MED, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, USER_IN_DEF_DKIM_WL, USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2021 17:17:35 -0000 On Tue, Apr 6, 2021 at 3:28 AM Richard Biener wrote: > > Seeing the word "dysfunction" I don't remember using I want to clarify > the non-openess which I intended to criticize. The SC is not "open" because: > - it appoints itself (new members, that is) - in fact in theory it > should be appointed > by the FSF because the SC is the GNU maintainer of GCC > - all requests and discussions are _private_ - the SC does not report to the > GCC project (it might report to the FSF which it is formally a delegate of) > - you can reach the SC only indirectly (unless you know the secret mailing list > it operates on) - CC an SC member and hope a request is forwarded > > now I understand the SC sees itself as buffer between GCC and the FSF (RMS > in particular) and it thinks we need to be protected from direct engagement. I > think this is wrong. I can very well say NO to RMS myself. > > I'm actually curious how many of the 13 SC members actively contribute or > whether the "SC show" is a one or two persons game and the "13" is just > to make the SC appear as a big representative group of people. > > Thus I request an archive of the SC mailing list be made publically available > and the SC discussion from now on take place in an open forum (you can > choose to moderate everybody so the discussion while carried out in open > is still amongst SC members only). To a first approximation, the only thing that the SC does is approve maintainers. Questions like Nathan's example of libcody are rare. To be pedantically clear, by "maintainers" I mean the people listed in the MAINTAINERS file who have the right to approve and commit changes to various parts of the compiler. While most discussion about approving maintainers is pro forma, there are sometimes discussions as to whether a particular person has the appropriate knowledge and sense of responsibility for the role. I don't think it would be appropriate to require that those discussions be held publically. In any case it wouldn't work; if they were required to be public, SC members would resort to private e-mail for anything they didn't want to be public. So perhaps one thing we should be talking about is: can we develop a mechanism for approving maintainers that does not involve the SC? For example, I am also involved with the Go language project. In that project, any existing maintainer (that is, any person with the right to commit changes to the repo) can approve any person to be a new maintainer. However, all changes require approval from at least two maintainers, and, of course there are people who take at least a quick look at every commit after it happens. The two maintainer rule is enforced by tooling, as all changes to Go must be made through Gerrit (https://www.gerritcodereview.com/). I'm not suggesting that we adopt this for GCC, just mentioning as an example of a different approach that does not require anything like the SC. I'm sure other people on this list can give examples of other approaches used by other free software projects. Ian