20/06/2023 16:10, Ferruh Yigit:
> On 6/20/2023 2:15 PM, humin (Q) wrote:
> > Hi, Niklas, Ferruh,
> >
> > 在 2023/6/20 19:03, Niklas Söderlund 写道:
> >> Hi Connor and Ferruh,
> >>
> >> On 2023-06-19 09:57:17 +0100, Ferruh Yigit wrote:
> >>> On 6/16/2023 1:00 PM, humin (Q) wrote:
> >>>> Hi,
> >>>>
> >>>> 在 2023/6/16 15:20, Chaoyong He 写道:
> >>>>> From: Zerun Fu <zerun...@corigine.com>
> >>>>>
> >>>>> After the mainline Linux kernel commit
> >>>>> "fe205d984e7730f4d21f6f8ebc60f0698404ac31" (ACPI: Remove side effect
> >>>>> of partly creating a node in acpi_map_pxm_to_online_node) by
> >>>>> Jonathan Cameron. When the system does not support NUMA architecture,
> >>>>> the "socket_id" is expected to be -1. The valid "socket_id" in
> >>>>> BOND PMD is greater than or equal to zero. So it will cause an error
> >>>>> when DPDK checks the validity of the "socket_id" when starting the
> >>>>> bond. This commit can fix this bug.
> >>>>>
> >>>>> Fixes: f294e04851fd ("net/bonding: fix socket ID check")
> >>>>> Cc: sta...@dpdk.org
> >>>>>
> >>>>> Signed-off-by: Zerun Fu <zerun...@corigine.com>
> >>>>> Reviewed-by: Peng Zhang <peng.zh...@corigine.com>
> >>>>> Reviewed-by: Chaoyong He <chaoyong...@corigine.com>
> >>>>> Reviewed-by: Long Wu <long...@corigine.com>
> >>>> No need add your colleagues unless they "reviwed-by" through
> >>>> email-list.
> >>>>
> >>> Hi Connor,
> >>>
> >>> This is done time to time, if code is already internally reviewed, send
> >>> review/ack tags within the patch, to reduce noise in the mail list.
> >> This is the reason why patches from us usually have 1 or 2 R-b tags when
> >> we post to the list. We have an internal review and CI pipeline we run
> >> patches thru to reduce the noise at the list and to not waste upstream
> >> review resources.
> >>
> >> We follow the DPDK workflow internally before we submit patches to the
> >> public mailing list. I hope we can continue to do so and add R-b tags,
> >> as they represent real effort by the developers.
> >
> > Actually, this is an interesting story.
> > The reason why I said so is I met same circumstances a few years ago.
> > Then I sent one patch with R-b tags which added internally by my
> > colleagues.
> >
> > Someone from mail-list said this was not right. From then on, every time I
> > send patches, I will delete R-b tags and send to mail-list.
> >
>
> For a driver, vendor and maintainers are experts and probably internal
> reviews are good enough. Most of the times details are not interesting
> to the rest of the community.
>
> But for code that impact multiple vendors, like libraries, it is good to
> have public reviews to share reasoning and updates and record them for
> future.
>
> Sometimes for this code that impact multiple vendor, if the author and
> maintainer are from same company, we receive a patch with maintainer's
> ack with it.
> This raises questions on how much it is reviewed, how many internal
> version it went through 1 or 11, or what was the design decision
> reasoning etc.. If these concerns felt somehow, explicit acks from
> maintainer requested time to time.
>
> Or for me, some obvious mistakes in patch, with maintainer's ack already
> embedded in it raises similar concerns and I request explicit ack.
>
> But technically there is nothing preventing ack to be embedded into
> patch itself.
Yes
If there is an internal review, you can embed the tag.
The decision of what is enough for a patch to be merged
is the role of the tree maintainer.
The component maintainer must make sure that the patches are well reviewed,
and the tree maintainer does a last check of trust & quality.
