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