| Message ID | 20230227103258.13295-2-philmd@linaro.org |
|---|---|
| State | New |
| Headers | show |
| Series | hw/vfio: Build various target-independent objects once | expand |
On 2/27/23 11:32, Philippe Mathieu-Daudé wrote: > Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Cédric Le Goater <clg@redhat.com> Thanks, C. > --- > hw/vfio/migration.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/hw/vfio/migration.c b/hw/vfio/migration.c > index a2c3d9bade..f9ac074c63 100644 > --- a/hw/vfio/migration.c > +++ b/hw/vfio/migration.c > @@ -24,7 +24,6 @@ > #include "migration/misc.h" > #include "qapi/error.h" > #include "exec/ramlist.h" > -#include "exec/ram_addr.h" > #include "pci.h" > #include "trace.h" > #include "hw/hw.h"
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, Alex > --- > hw/vfio/migration.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/hw/vfio/migration.c b/hw/vfio/migration.c > index a2c3d9bade..f9ac074c63 100644 > --- a/hw/vfio/migration.c > +++ b/hw/vfio/migration.c > @@ -24,7 +24,6 @@ > #include "migration/misc.h" > #include "qapi/error.h" > #include "exec/ramlist.h" > -#include "exec/ram_addr.h" > #include "pci.h" > #include "trace.h" > #include "hw/hw.h"
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. thanks -- PMM
Alex Williamson <alex.williamson@redhat.com> writes: > 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 think that is a little unfair for this case as the motivation and action are all covered by the summary line. Granted the overall goal is covered by the cover letter and the following patch however for this patch I would hope its self explanatory. Anyway: Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
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, Alex
On Mon, 27 Feb 2023 16:24:16 +0000 Alex Bennée <alex.bennee@linaro.org> wrote: > Alex Williamson <alex.williamson@redhat.com> writes: > > > 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 think that is a little unfair for this case as the motivation and > action are all covered by the summary line. Granted the overall goal is > covered by the cover letter and the following patch however for this > patch I would hope its self explanatory. The commit title only conveys that the include is unused and the action to therefore remove it. The motivation is actually to create target independent objects and the specific reasoning here is that not only is this include file unnecessary, but forces per target builds. This is exactly the "barrier to entry" I mention to Peter, it's obvious to the experts in the crowd, but it provides no underlying direction for those who might be more novice. There is always some reasoning that can be included in a commit log beyond the simple "a therefore b" of the commit title. Thanks, Alex
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.
Alex Williamson <alex.williamson@redhat.com> writes: > On Mon, 27 Feb 2023 16:24:16 +0000 > Alex Bennée <alex.bennee@linaro.org> wrote: > >> Alex Williamson <alex.williamson@redhat.com> writes: >> >> > 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 think that is a little unfair for this case as the motivation and >> action are all covered by the summary line. Granted the overall goal is >> covered by the cover letter and the following patch however for this >> patch I would hope its self explanatory. > > The commit title only conveys that the include is unused and the action > to therefore remove it. The motivation is actually to create target > independent objects and the specific reasoning here is that not only is > this include file unnecessary, but forces per target builds. I've been guilty of submitting patches with just a subject line, too. E.g. commit 6f1e91f716a (error: Drop superfluous #include "qapi/qmp/qerror.h"): I could have written that the header's contents should go away, and the less we include it, the better. I should have. > This is exactly the "barrier to entry" I mention to Peter, it's obvious > to the experts in the crowd, but it provides no underlying direction > for those who might be more novice. There is always some reasoning > that can be included in a commit log beyond the simple "a therefore b" > of the commit title. Thanks, Sometimes, the motivation is so obvious that omitting it for brevity's sake feels harmless enough. E.g. for commit 15b7646c7d0 (monitor: Drop unnecessary includes) it's really just "include less to remake less". Of course, when you explain motivation in the cover letter, it's almost certainly best to explain it again in the commit messages.
On 27/02/2023 17.04, Peter Maydell 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. But not giving any description at all is really just bad style, we should avoid it. And in this case, there is even a good reason that should be mentioned here (e.g. "This header was the only reason this file needed to be built per target"). So I think it's fair to ask for a proper commit log message here. Thomas
diff --git a/hw/vfio/migration.c b/hw/vfio/migration.c index a2c3d9bade..f9ac074c63 100644 --- a/hw/vfio/migration.c +++ b/hw/vfio/migration.c @@ -24,7 +24,6 @@ #include "migration/misc.h" #include "qapi/error.h" #include "exec/ramlist.h" -#include "exec/ram_addr.h" #include "pci.h" #include "trace.h" #include "hw/hw.h"
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> --- hw/vfio/migration.c | 1 - 1 file changed, 1 deletion(-)