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

[Nicolai Hähnle via llvm-dev]

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