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

[Neal Gompa]

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:
> > On Thu, Jul 16, 2020 at 03:44:25PM +0200, Pavel Hrdina wrote:
> > > On Thu, Jul 16, 2020 at 01:59:00PM +0100, Daniel P. Berrangé wrote:
> > > > Personally I'd really like to avoid squashing them, because splitting
> > > > up big patches is not merely to benefit the initial pre-merge review,
> > > > but to also benefit people who need to debug stuff that's already
> > > > merged and understand the scope of the intended change. So being able
> > > > to look back at the changes in isolation after commit is still a big
> > > > plus point.
> > >
> > > I would like to avoid squashing the patches as well and in most cases I
> > > would object to it as well. I only suggested that to not break git
> > > bisect.
> > >
> > > If we don't care about git bisect and the fact that we would not be able
> > > to build libvirt correctly within these patches I'm OK with pushing it
> > > without squashing.
> >
> > git bisect reliabity is key, so I reluctantly think we'll need to
> > squash. I don't want to hit a pathc in this series with a bisect
> > and be unable to continue the bisect due to inability to build the
> > code.
>
> 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
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. 😅

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. Or maybe this could be the inaugural change merged in
through a merge request in GitLab.com?

One could only hope...


-- 
真実はいつも一つ！/ Always, there's only one truth!