[libvirt PATCH 000/351] port libvirt to Meson build system

[Peter Krempa]

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 at 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.