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

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>

Hey Chris (Lattner), mentioned this on the review thread, but we're waiting
on you to take a look at the pitch (step 4 of the process)

On Tue, Jan 12, 2021 at 5:58 PM Geoffrey Martin-Noble <gcmn at google.com>
wrote:
> 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/20210128/d8eaa868/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/20210128/d8eaa868/attachment-0001.bin>