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

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>

Ok, hearing no objections and given that folks have already started
commenting on the phab patch, let's concentrate discussion there.

On Mon, Jan 11, 2021 at 2:45 PM Chris Tetreault <ctetreau at quicinc.com>
wrote:
> 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/20210112/fe1523b2/attachment-0001.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/20210112/fe1523b2/attachment-0001.bin>