Re: Getting whole-tree patches reviewed and merged

[Paolo Bonzini <pbonzini@redhat.com>]

On 07/02/20 22:53, Eric Blake wrote:
> On 1/21/20 11:16 PM, Markus Armbruster wrote:
>> Peter Maydell <peter.maydell@linaro.org> writes:
>>
>>> On Tue, 21 Jan 2020 at 15:11, Marc-André Lureau
>>> <marcandre.lureau@gmail.com> wrote:
>>>> There are plenty of refactoring to do. The problem when touching the
>>>> whole code-base, imho, is review time. It may take a couple of
>>>> hours/days to come up with a cocci/spatch, and make various patches
>>>> here and there. But it takes often weeks and a lot of constant push to
>>>> various folks to get all the reviews (as seens by the qdev prop-ptr
>>>> series earlier for example). How can we better address whole code-base
>>>> changes?
>>>
>>> It depends. If it's literally just a cocci/spatch mechanical
>>> transformation, I think we should be OK with reviewing that
>>> transform and then applying it; we don't need to get acks
>>> from every submaintainer for that kind of thing.
>>
>> I go one step further: I prefer mechanical changes committed together,
>> not torn apart and routed through N+1 trees, where N is the number of
>> active maintainers picking patches from the series, and 1 is the
>> maintainer taking pity of the inevitable leftovers.
>>
>> Tearing a patch series apart may be in order when it's invasive enough
>> to risk many conflicts.  The subsystem maintainer may need tighter
>> control over merging order then, and routing picked patches through his
>> own tree may be the practical way to get it.
> 
> And the pending work on ERRP_AUTO_PROPAGATE is an example of that -
> Vladimir has been trying to get the improvements in for some time, but
> it touches so many files, and is awkward to review whether it is split
> into over 100 patches per maintainer area or when it is consolidates
> into few but large patches.

If I can help with ERRP_AUTO_PROPAGATE, I can merge it through my tree.

Paolo