llvm dev - Jan 2021 - [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/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>

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>