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

[Chris Tetreault via llvm-dev]

> [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