Re: [Xen-devel] [PATCH 00/18] x86: more bool_t to bool cleanup

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 30.06.17 at 19:01, <wei.liu2@xxxxxxxxxx> wrote:
> Seeing that bool_t keeps creeping back in new patches I think the only 
> solution
> is to get rid of bool_t once and for all, as soon as possible.

I don't fully agree, and considering the flood of patches you're
submitting in this area I think I finally need to voice my opinion
here (I had really meant to only do this in Budapest, on a BoF
I mean to propose): I appreciate you having and taking the
time to do this cleanup. Nevertheless I'm not overly happy with
it. For one, it requires time (even if not very much) to review.
And as you likely know, patch volume and review bandwidth
don't really fit together very well. (I had managed to deal with
all my old, non-RFC reviews during the last week, only to find
I'm again at almost 50 again this morning, and I haven't
finished working through the all the xen-devel traffic having
come in over the weekend. This is simply frustrating.)

It would perhaps be okay if no comments were needed at all,
but I think in all of the series you sent to this effect there were
further corrections necessary (leaving aside merely desirable
ones). Especially bulk cleanup work like this should introduce as
little overhead to others as possible. Hence the comments here
also apply to the PV code splitting work you've apparently
invested quite a bit of time into.

Furthermore there's the issue of backports: If cleanups like
these are being done over time (as code is being touched
anyway), backports (security and non-security ones) generally
go more smoothly.

But as said, I mean to bring the overall situation up in
Budapest, so I'm not sure how much of need should / needs
to be discussed up front via mail.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel