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

[Geoffrey Martin-Noble via llvm-dev]

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/3382aa4c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3992 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210111/3382aa4c/attachment.bin>