Re: [PATCH v4 2/3] module: add Error arguments to module_load_one and module_load_qom_one

[Markus Armbruster <armbru@redhat.com>]

Claudio Fontana <cfontana@suse.de> writes:

> Hi Markus, sorry for the harsh response last week, it comes from a position of lack of time,
> and the expectation that Richard's review would be enough.

I gladly accept your apology.

We had the good fortune to meet in person (at KVM Forums before the
plague).  Makes it so much easier to react "good guy is having a bad
day, try to help" instead of "bad guy, avoid".

> I don't have (and I suspect no one that is not 100% working on qemu "upstream" and cannot hang around IRC channels or such)
> good visibility of what happens to patches after they are reviewed like in this case,
> so this makes the process in my view overall quite unpredictable and seems to require a lot of time investment for even the smallest change.

I understand.  It's a common complaint.

> That is why I would generally prefer smaller chunks of work to be committed incrementally, each series self-contained,
> rather than hundred-patch series that I expect to lose momentum or get lost.
>
> There are things we can fine tune here, but I see some of the changes you propose as going beyond what a fix for the acute problem really requires,
> so if this series requires a lot of work in your view for even the minimal fix to be done, I think we will need someone else to step in and expand on the work,
>
> or we will have to keep the fix as downstream-only for now, and I'll try to find more time to invest early next year.

That's fair.

We can accept patches that don't solve the entire problem.  I still like
to understand the entire problem to a useful degree, and have a rough
idea of how a solution of the entire problem could look like.

We may then conclude that such a solution isn't in the cards right now,
but a partial solution is, so we better take it.

Sometimes, the proposed patch turns out to be not even a partial
solution (but we recognize that only now we understand the entire
problem).  Then we better reject it.

Trouble is that developing such an understanding in patch review can
easily come over as non-negotiable demands.  This can be frustrating and
demoralizing for patch submitters.  I try to avoid this trap, but I
don't always succeed.  When understanding the patch and the problem
consumes 95% of my poor brain's capacity, I'm left with 5% for
communicating...  and when 5% aren't enough, I need to apologize for not
expressing myself clearly.