Re: [PATCH 1/2] hw/vfio/migration: Remove unused 'exec/ram_addr.h' header

[Philippe Mathieu-Daudé]

Hi Alex,

On 27/2/23 17:34, Alex Williamson wrote:
> On Mon, 27 Feb 2023 16:04:16 +0000
> Peter Maydell <peter.maydell@linaro.org> wrote:
>
> > On Mon, 27 Feb 2023 at 15:46, Alex Williamson
> > <alex.williamson@redhat.com> wrote:
> > > On Mon, 27 Feb 2023 11:32:57 +0100
> > > Philippe Mathieu-Daudé <philmd@linaro.org> wrote:
> > >   
> > > > Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
> > >
> > > Empty commit logs are a pet peeve of mine, there must be some sort of
> > > motivation for the change, something that changed to make this
> > > possible, or perhaps why this was never necessary.  Thanks,
> >
> > I generally agree, but "this file doesn't actually need to
> > include this header" seems straightforward enough that the commit
> > subject says everything you'd want to say about it.
> > The underlying reason is going to be one of:
> >   * this used to be needed, but somewhere along the line the
> >     thing the file needs moved to a different header
> >   * this used to be needed, but the code in the file changed
> >     and no longer uses the thing the header was providing
> >   * this was never needed, and the include was just cut-n-pasted
> >     from a different file when the file was originally written
> >
> > Tracking down which of those is the case for every single
> > "file is including unnecessary headers" cleanup seems like
> > a lot of work trawling through git histories and doesn't
> > really provide any interesting information.
>
> OTOH, not providing any justification shows a lack of due diligence.
> Even a justification to the extent of "This passes gitlab CI across all
> architectures after removing the include" or copying from the cover
> letter to explain that this include is the only reason the file is
> built per target would be an improvement.
>
> I find that empty commit logs create a barrier to entry for
> participation in a project, there is always some motivation that can
> help provide a better commit that doesn't force an undue burden on the
> submitter.  Thanks,

You are totally right and I apologize for such low quality patch.
If I want these cleanups to scale (being done by other) I certainly
need to explain why they are useful. Eventually copy/pasting the
same reasoning for class of change.
OTOH I sometime feel these cleanups are more noise than anything
to maintainers, and various end up queued via qemu-trivial@
(which isn't what I expect for trivial@).
We have a bit of both, maintainers tired by poor descriptions /
justifications, and contributors exhausted to get trivial patch
- for their perspective - merged without too much doc.

This patch you insist on is a good one-line example of a pattern
we should start cleaning: being overzealous with header included
pull so many stuff that we shoot on our foot and end in weird
corner cases, such here making an object target-dependent when
it isn't.
target-dependent objects add build complexity, and delay us from
the goal of single binary and heterogeneous emulation.

Good English explanation for non-English native speaker is not
easy as native speaker, but usually the community is opened and
bare with that barrier.

I'll reword to something work committing and referring to later,
when looking at git history.

Thanks for insisting in improving us!

Phil.