From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from resqmta-h1p-028596.sys.comcast.net (resqmta-h1p-028596.sys.comcast.net [IPv6:2001:558:fd02:2446::4]) by sourceware.org (Postfix) with ESMTPS id 087443858C54 for ; Fri, 12 Aug 2022 20:46:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 087443858C54 Received: from resomta-h1p-027911.sys.comcast.net ([96.102.179.202]) by resqmta-h1p-028596.sys.comcast.net with ESMTP id MZzroqH25iOImMbXforCsT; Fri, 12 Aug 2022 20:46:03 +0000 Received: from smtpclient.apple ([IPv6:2601:640:4100:880:31b2:2fb9:8d22:281a]) by resomta-h1p-027911.sys.comcast.net with ESMTPSA id MbXSoqsqUOZYxMbXTo0Fxu; Fri, 12 Aug 2022 20:46:00 +0000 X-Xfinity-VMeta: sc=-100.00;st=legit Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\)) Subject: Re: Rust frontend patches v1 From: Mike Stump In-Reply-To: Date: Fri, 12 Aug 2022 13:45:49 -0700 Cc: gcc-patches@gcc.gnu.org, manu@gcc.gnu.org Content-Transfer-Encoding: quoted-printable Message-Id: <6206013C-5EB5-48CE-A41D-3E39D6F2ADBB@comcast.net> References: <20220727134040.843750-1-philip.herron@embecosm.com> <52031efabcd85759ff3bf3a4d0c6a4ff0b47128e.camel@redhat.com> To: Philip Herron X-Mailer: Apple Mail (2.3696.100.31) X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, JMQ_SPF_NEUTRAL, KAM_NUMSUBJECT, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2022 20:46:08 -0000 On Aug 10, 2022, at 11:56 AM, Philip Herron = wrote: >=20 > For my v2 of the patches, I've been spending a lot of time ensuring > each patch is buildable. It would end up being simpler if it was > possible if each patch did not have to be like this so I could split > up the front-end in more patches. Does this make sense? In theory, > when everything goes well, does this still mean that we can merge in > one commit, or should it follow a series of buildable patches? I've > received feedback that it might be possible to ignore making each > patch an independent chunk and just focus on splitting it up as small > as possible even if they don't build. It is a waste of time to make each build. The all go in together, or = not at all. The patches are split for review only. You can then = maintain approval status for each individually and perform adjustments = and updates for each patch. Once all pieces have been approved in their final form, you can then = commit the whole at once. It is this commit, before you commit, that = you regression test, integration test, and ensure that final form is = good. If not, you bounce back to update for all the pieces that need = it, approval for those edits, and lather, rinse, repeat. It is handy for larger work (like this) to be on a git branch so that = followers can see the totality of the work and experiment with it in the = large. I'd usually do the commit to the main branch as a squashed = commit without the review edit histories or the "bad stuff" the = reviewers had you change or the merge records even.=