Re: Getting whole-tree patches reviewed and merged

[Markus Armbruster]

Paolo Bonzini <address@hidden> writes:

> On 07/02/20 22:53, Eric Blake wrote:
>> On 1/21/20 11:16 PM, Markus Armbruster wrote:
>>> Peter Maydell <address@hidden> writes:
>>>
>>>> On Tue, 21 Jan 2020 at 15:11, Marc-André Lureau
>>>> <address@hidden> 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.

Right now I'm to blame: I need to review the infrastructure and its
pattern of use.

Once that's done, the next questions are what level of review we want
for the instances of the pattern, and how to merge the thing.

One way is to split along subsystems boundaries, and ask subsystem
maintainers to merge their part.  Infrastructure has to go first, of
course.  That would be my job as error subsystem maintainer.  Getting
everything merged via pretty much every subsystem we have will likely be
a drawn out affair.

Another way is to go ahead and merge everything, damn the torpedoes.