qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Markus Armbruster
Subject: Re: [DRAFT PATCH 000/143] Meson integration for 5.2
Date: Fri, 07 Aug 2020 11:02:34 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)

Daniel P. Berrangé <berrange@redhat.com> writes:

> On Fri, Aug 07, 2020 at 09:56:42AM +0200, Markus Armbruster wrote:
[...]
>> 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.

I had less than a "now and over next month" (>7 weeks!) in mind.

The choice of deadline is really about how much of Paolo's time we are
(and he is!) willing to spend on rebasing vs. how much risk of toothing
problems in master we are willing to accept.

"First thing after 5.2 opens" would be ideal from a "avoid more
rebasing" point of view, but it may not be practical.

Once the flood gates are open, we can probably just as well wait for the
initial flood to subside.

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

Yup.  If you want it not to break in master, get it tested in our gating
CI.

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]