[llvm-dev] [PITCH]: Allow Unsupported Build Configurations in the LLVM Monorepo

[Chris Tetreault via llvm-dev]

This all sounds reasonable to me. I think having a phab review for the text of the proposal makes sense. This allows people to suggest changes inline.

From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Geoffrey Martin-Noble via llvm-dev
Sent: Monday, January 11, 2021 2:15 PM
To: LLVM Dev <llvm-dev at lists.llvm.org>; Eric Christopher <echristo at google.com>; Chris Lattner <clattner at nondot.org>; Tom Stellard <tstellar at redhat.com>; Renato Golin <rengolin at gmail.com>; chris.bieneman at me.com
Subject: [EXT] [llvm-dev] [PITCH]: Allow Unsupported Build Configurations in the LLVM Monorepo

Now that most folks are back from the holidays, I'm starting a proposal pitch, as part of the LLVM Proposal Process<https://github.com/llvm/llvm-www/blob/master/proposals/LP0001-LLVMDecisionMaking.md>, for allowing unsupported build configurations in the LLVM monorepo. This is a followup to past<https://groups.google.com/g/llvm-dev/c/u07o3QREVUg/> discussion<https://groups.google.com/g/llvm-dev/c/HJbDaP-lvV0>. The motivating example is Bazel, but since the controversy was around the inclusion of unsupported build systems in-tree in general, this proposal addresses that issue in a general sense.

First, some procedural points: since this is basically the first time the new pitch process is being used, I don't have a lot of examples to draw on. Chris's initial proposal for this process itself is the only example and I think it was unsurprisingly unusual given that the process it was following did not yet exist.

Discussion format: I'm not sure where the best place to discuss the text of the proposal is. Given that the intended final artifact is a checked in markdown file in llvm-www, I started this as a Phab patch (https://reviews.llvm.org/D94451). Personally, I think that concentrating the discussion on Phab and basically conducting it as a review would be the most fruitful for this phase of the discussion. My understanding is that the goal at this point is not necessarily to involve the widest section of the community possible, but rather to produce a formal proposal with which to do so, so the wide visibility of the dev list seems less important here except for this initial email that points interested parties to the right place. For that reason, I've held off on including the text of the proposal in this email. I could instead paste it here and we can discuss it, with me porting updates to the patch.

Review managers: The proposal guidelines say to pick 2 or 4 reviewer managers, I assume so that it's an odd number once adding Chris. I've proposed 6 potential review managers and will explain my rationale for each, but I think we should probably drop some so we have at most 4 + Chris.

- Geoffrey Martin-Noble: me, the author of this proposal. It was not clear to me whether the author must, should, or should not be one of the review managers. I'm happy to either do this or not. I have been the one driving this proposal, so it makes some sense. On the other hand, I'm a relatively new member of the LLVM community without as much context on its mores, history and decision making processes.
- Chris Lattner: This is the first usage of the new process, so it might make some sense to have some additional steering. Chris will be part of the final decision regardless, so whether he's formally a review manager is maybe less important.
- Tom Stellard: Was actively involved in the previous discussions and stated some concerns and objections, pushing for the use of the proposal process. As release manager, can speak to how the proposal might affect releases.
- Renato Golin: Was actively involved in the previous discussions and stated some concerns. Authored the new LLVM Support Policy<http://llvm.org/docs/SupportPolicy.html>, which is part of this discussion.
- Eric Christopher: Was actively involved in some of the past discussions. Previous build LLVM build system maintainer.
- Chris Bieneman: Previous LLVM build system maintainer. Was not actively involved in past discussions.

Obviously, all of these suggestions are dependent on the person in question agreeing to act as review manager.

Again the actual proposal is in this patch (https://reviews.llvm.org/D94451), but let's settle the discussion format first (which hopefully will be easy) so we don't end up with a fragmented discussion.

Thanks!
Geoffrey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210111/5b46739e/attachment.html>