Re: [DRAFT PATCH 000/143] Meson integration for 5.2

[Daniel P . Berrangé]

On Fri, Aug 07, 2020 at 09:56:42AM +0200, Markus Armbruster wrote:
> Paolo Bonzini <pbonzini@redhat.com> writes:
> 
> > This the more or less final version of the Meson conversion.  Due to
> > the sheer size of the series you have been CCed only on the cover
> > letter.
> 
> Perfect timing: right before I drop off for two weeks of vacation.  I'm
> excused!  *Maniacal laughter*
> 
> > The series reaches the point where Makefile.target and unnest-vars
> > can be removed, and all builds become non-recursive.  I have also
> > converted parts of the testsuite, notably qtest since it is needed
> > for fuzzing.  What's left for _after_ the merge is: 1) unit tests;
> > 2) moving the rest of installation to meson (for which I have patches);
> > 3) moving feature detection from configure to meson.
> >
> > Things I still haven't tested:
> > - fuzzing
> > - non-x86/Linux builds
> > - static builds
> > - Docker and VM builds
> >
> > Things I have checked:
> > - x86 builds
> > - modules
> > - "make install"
> > - internal slirp/dtc/capstone.
> 
> Have you run it through our CI?
> 
> > It should be more or less bisectable.  I have not tried building
> > _all_ steps, but I have tried both before and after each major one.
> >
> > Build system rebuild rules seem to work reliably.
> 
> Is it faster in common build scenarios?
> 
> > After a week or quite intense rebasing, my impression is more or less
> > the same as last December: Meson looks more daunting, but it is actually
> > much nicer to work with.
> 
> Not a particularly high bar to cross: our Makefiles are full of the kind
> of black magic that keeps simple things simple (which is quite an
> achievement; kudos!), and makes not-so-simple things really hard.
> 
> I think it's now time to plan the end game, preferably without even more
> weeks of intense rebasing.
> 
> Do we have consensus to move forward with Meson?  If yes, I'd like to
> propose to aim for merging as early as practical in the 5.2 cycle.
> Rationale: rebasing build system changes on top of the Meson work is
> probably easier than rebasing the Meson work, and avoids turning Paolo
> into an overworked bottleneck.
> 
> In more detail:
> 
> 1. Pick a tentative deadline.

I'd suggest we need a bare minimum of half a development cycle to.
So if we want it tin 5.2, we need to make a strong push now and over
next month to review it and iron out any obvious blocking testing
problems.

> 2. Cover the testing gaps and get as much review as we can until then.
>    Fix defects as we go.

In terms of testing I'd suggest the minimium bar is likely the GitLab CI
and Peter's merge scripts.

Anything beyond that is just nice to have.

> 3. If the known defects are expected to disrupt others too much, goto 1.
>    Do not worry about unknown defects at this point.
> 
> 4. Merge.
> 
> 5. Deal with the fallout.

Yep, there's no substitute for getting it used for real by a wide
range of people, which is why we we need leave ourselves at min
1/2 a dev cycle for this.


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 :|