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

[Daniel P. Berrangé]

On Fri, Jul 17, 2020 at 04:10:01PM +0200, Pavel Hrdina wrote:
> On Fri, Jul 17, 2020 at 03:02:10PM +0100, Daniel P. Berrangé 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 can try to rearrange the patches to not break git bisect. It will
> still require some script to be used for git bisect to detect if it
> should run autotools or Meson.

Maybe there's a reasonable tradeoff - instead of a 350 patch series,
just a 10-20 patch series. 

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|