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