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

[Philippe Mathieu-Daudé]

On 8/7/20 10:22 AM, Daniel P. Berrangé wrote:
> 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.

Any merge request not changing buildsys (configure/Makefile), adding new
(or moving) .c files shouldn't be a problem.

I have that feeling that Meson will have less bottleneck problem than
our Perl scripts =)

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

Just to clarify, does the "dev cycle" include the freeze window?

QEMU produces a release every 17 weeks, the dev cycle is usually 12
weeks then we have 4 (+1) weeks of stabilization for the release.

So the plan is to get this merged approximately 6 weeks after the
next release, right?

Regards,

Phil.

> 
> 
> Regards,
> Daniel
>