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

[Geoffrey Martin-Noble via llvm-dev]

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>