llvm dev - Jun 2020 - [PROPOSAL] Introduce a new LLVM process to resolve contentious decisions

> [RE: adding an RFCs/Proposals mailing list] I'm not enthusiastic about
this and would rather avoid it. Adding a new mailing list is potentially
acceptable as long as the rule is that proposals **must** be cross-posted to the
relevant project mailing lists. E.g., if we have a proposals at lists.llvm.org,
any proposals affecting LLVM itself must also still go to llvm-dev at
lists.llvm.org.
I would actually argue that the rule should be that RFCs **must not** be
cross-posted anywhere but the RFCs mailing list. My reasoning for this:

1) In my opinion, anybody interested in driving the overall design of the
project should be subscribed to the RFCs mailing list, so they will see the
RFCs.
2) The before-mentioned "you are not subscribed to this mailing list"
issue. When messages are posted to n different mailing lists, you often get n-1
rejection emails. Realistically, many people are not going to go subscribe to
the relevant mailing list and resend, they're just going to say "well,
I guess the [whatever project] folks aren't going to see that one".
3) It will reduce noise. This will mean that other types of messages get higher
visibility in their respective mailing list as they won't have to compete
with 30 different replies to "RFC: The bike shed should be green".
4) It ensures that everybody who cares about RFCs (as defined by "you would
be subscribed to the RFCs maling list if you care about RFCs") will see
every RFC. Often, some RFC will be churning along in cfe-dev, then get cross
posted to llvm-dev. Then, since not everybody is subscribed to both of those
mailing lists, many people will only see parts of the conversation as some
messages will get put in the mod queue for one or the other, never to be seen
again.

I do agree that the RFCs mailing list should not bounce any messages. Is it
possible to configure it to skip the moderation queue if the sender is a member
of any llvm project mailing list?

-----Original Message-----
From: Nicolai Hähnle <nhaehnle at gmail.com>
Sent: Wednesday, June 10, 2020 12:49 PM
To: Chris Tetreault <ctetreau at quicinc.com>
Cc: Chris Lattner <clattner at nondot.org>; llvm-dev at lists.llvm.org
Subject: [EXT] Re: [llvm-dev] [PROPOSAL] Introduce a new LLVM process to resolve
contentious decisions

My overall impression of the proposal is positive. Like Mehdi, my thinking is
that starting with a *lightweight* process is an improvement. If the process has
bugs, we should strive to fix them.
The process as proposed is lightweight enough that it seems like a good start.
That said, some thoughts:

The proposal does not at all address the problem of total silence.
Some RFCs just don't receive any response, and then people are uncertain
about what that means. Silent agreement? Don't care? Some RFCs don't
come with immediate code changes, so it may not matter too much -- proposals
without code can be difficult to evaluate anyway.
But what about RFCs where the submitter plans to make commits fairly soon? I
tend to feel like acting first and asking for forgiveness later in such cases,
but what's a reasonable time to wait through radio silence?

I'm looking forward to putting that particular question to the test in the
not-too-distant future ;)

Other points:
> 2 weeks might be a bit short of a discussion period for major policy
changes. Many people go on vacation for that amount of time, and it would be
unfortunate to come back from vacation and find that some major decision went in
while you were out.
I tend to agree. While the process as a whole is obviously going to be longer
anyway due to the RFC and PITCH phases, if being inclusive is part of the goal,
then 3 weeks should probably be the minimum on contentious issues.

> I think a separate mailing list would be good for these. RFC’s should also
go into this new mailing list, so people who are too busy to follow
[whatever]-dev can at least keep up to date on the RFC’s mailing list. I think
that it would also be good to have all the subproject RFC’s in once place; more
than once I’ve seen an RFC get cross-posted to llvm-dev, then tried to reply and
got the “your message is being held for moderation” message because I’m not
subscribed to flang-dev (or whatever mailing list). This might also have the
side benefit of reducing noise on the subproject mailing lists if RFC’s are not
posted (or cross posted) there.
I'm not enthusiastic about this and would rather avoid it. Adding a new
mailing list is potentially acceptable as long as the rule is that proposals
**must** be cross-posted to the relevant project mailing lists. E.g., if we have
a proposals at lists.llvm.org, any proposals affecting LLVM itself must also
still go to llvm-dev at lists.llvm.org.

The thing is, if we do this, then as a corollary the new mailing list would
realistically have to accept mails sent by anybody, not just people subscribed
to that list. This may make having the new list infeasible in practice.

Cheers,
Nicolai