From: Mike Stump <mikestump@comcast.net>
To: Philip Herron <philip.herron@embecosm.com>
Cc: gcc-patches@gcc.gnu.org, manu@gcc.gnu.org
Subject: Re: Rust frontend patches v1
Date: Fri, 12 Aug 2022 13:45:49 -0700 [thread overview]
Message-ID: <6206013C-5EB5-48CE-A41D-3E39D6F2ADBB@comcast.net> (raw)
In-Reply-To: <CAB2u+n1V3P_+Qx6gxVvnLrfL=sFU6f2x4RzG3kpjs6XHoNy-5g@mail.gmail.com>
On Aug 10, 2022, at 11:56 AM, Philip Herron <philip.herron@embecosm.com> wrote:
>
> 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.
next prev parent reply other threads:[~2022-08-12 20:46 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-27 13:40 herron.philip
2022-07-27 13:40 ` [PATCH Rust front-end v1 1/4] Add skeleton Rust front-end folder herron.philip
2022-07-27 13:40 ` [PATCH Rust front-end v1 2/4] Add Rust lang TargetHooks for i386 and x86_64 herron.philip
2022-07-28 9:57 ` Jakub Jelinek
2022-07-28 10:38 ` Thomas Schwinge
2022-07-28 10:51 ` Philip Herron
2022-07-28 11:08 ` Thomas Schwinge
2022-07-28 11:41 ` Philip Herron
2022-07-27 13:40 ` [PATCH Rust front-end v1 3/4] Add Rust target hooks to ARM herron.philip
2022-07-27 14:13 ` Richard Earnshaw
2022-07-27 16:45 ` Rust frontend patches v1 David Malcolm
2022-07-28 9:39 ` Philip Herron
2022-08-10 18:56 ` Philip Herron
2022-08-10 19:06 ` David Malcolm
2022-08-12 20:45 ` Mike Stump [this message]
2022-08-15 14:07 ` Manuel López-Ibáñez
2022-08-15 14:33 ` Martin Liška
2022-08-24 13:48 ` Martin Liška
2022-08-24 13:51 ` Philip Herron
2022-08-24 14:02 ` Martin Liška
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6206013C-5EB5-48CE-A41D-3E39D6F2ADBB@comcast.net \
--to=mikestump@comcast.net \
--cc=gcc-patches@gcc.gnu.org \
--cc=manu@gcc.gnu.org \
--cc=philip.herron@embecosm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).