On Mon, Jul 27, 2020 at 20:43:05 -0400, Neal Gompa wrote:
On Mon, Jul 27, 2020 at 12:11 PM Peter Krempa
<pkrempa(a)redhat.com> wrote:
> On Fri, Jul 17, 2020 at 15:02:10 +0100, Daniel Berrange wrote:
[...]
> I agree. It's definitely necessary that the build is
complete at any
> point in time.
>
> I'm reluctantly willing to accept that the build fails with an
> appropriate error message until the build system is able to build
> everything if we opt for commiting a patchset for simplicity. What's
> off-limits is if build "succeeds", but is incomplete due to missing
> steps in the implementation. I'm not going to want to guess which part
> is already built or which isn't.
>
> Given that the rewrite is a singularity anyways it doesn't really matter
> that we will not be able to bisect problems caused by the build system
> across the boundary.
>
Unfortunately, this is where email based workflows completely fall
apart. If this was represented as a merge request, it'd be
straightforward to look at it from either the "changeset view" (the
delta from upstream main branch and the branch containing the changes)
or the "per-change view" (the delta across a commit). I literally
You can do the same once you apply the patches on your local repository.
In the end a the merge request is just that. A repo with the patches
applied and the "cover letter" is represented as the merge request
"justification".
The only difference is how you get those ...
could not figure out how to review this entire change set (despite
my
best efforts) because pulling down this 351-patch changeset is quite
difficult for me. At least, not until I realized the cover letter
pointed to a GitLab repository with the commits present.
... and Pavel provided both views in case your e-mail client doesn't
enable you to extract a patchset quickly.
Please note that in my reply I was specifically refering only to the
state once it's commited to the main repository and not in any way
refering to review. Once the patchset is comitted it's same situation
for everybody.
But email is the workflow we have, not the one we deserve, so
I'd
rather see this re-sent as a single patch. That patch will be too big
to send as an email, though, so it will likely need to be sent as an
attachment.
The resulting squashed mail is 880K. We had bigger ones e.g. when Daniel
changed the translation systems which had 1.0M and 1.2M emails and they
went through just fine.