On Tue, Apr 6, 2021 at 3:28 AM Richard Biener <richard.guent...@gmail.com> 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
