On Aug 10, 2022, at 11:56 AM, Philip Herron <philip.her...@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.
