From: Moritz Fischer <mdf@kernel.org>
To: Tom Rix <trix@redhat.com>
Cc: Greg KH <gregkh@linuxfoundation.org>,
Moritz Fischer <mdf@kernel.org>,
"linux-fpga@vger.kernel.org" <linux-fpga@vger.kernel.org>,
linux-kernel@vger.kernel.org, moritzf@google.com,
Rikard Falkeborn <rikard.falkeborn@gmail.com>,
Zheng Yongjun <zhengyongjun3@huawei.com>,
Russ Weight <russell.h.weight@intel.com>,
"Gerlach, Matthew" <matthew.gerlach@intel.com>,
Sonal Santan <sonal.santan@xilinx.com>,
Xu Yilun <yilun.xu@intel.com>,
Richard Gong <richard.gong@intel.com>
Subject: Re: [PATCH 0/8] FPGA DFL Changes for 5.12
Date: Mon, 11 Jan 2021 12:28:41 -0800 [thread overview]
Message-ID: <X/y0+ZCPsfrg/LUp@archbook> (raw)
In-Reply-To: <dccc8075-b900-8680-3620-8050475858a7@redhat.com>
Tom,
On Mon, Jan 11, 2021 at 11:46:03AM -0800, Tom Rix wrote:
[..]
> I have been doing the first review in a couple of days after every patch landing.
I appreciate your help with doing reviews.
> I see some pretty good response from the developers to fix the issues raised.
... yet patches have been rejected. So it doesn't seem purely a matter
of throughput?
> But I do not see Moritz picking up the review until weeks later.
I'll admit there are delays that happen, I have a dayjob as I pointed
out in earlier conversations. Furthermore, just because I do not
immediately send out an email does not mean I don't look at stuff.
If people show up with 100kLOC patchsets that don't pass checkpatch,
it'll take a while for me to even read up and understand what they're
doing / trying to do.
> This consistent delay in timely reviews is a bottleneck.
As Greg pointed out even ones that were reviewed got rejected, so
clearly the issue is with the quality and not the speed at which we send
them on.
> It would be good if the big first reviews could be done in parallel.
Again depending how the patchsets are structured it will take me a while
to process. Having them re-use existing infrastructure, following
coding and submission guidelines will speed up the process.
On a personal level, being told I'm too slow and not doing my job as
maintainer doesn't exactly increase my motivation to get to it ...
- Moritz
next prev parent reply other threads:[~2021-01-11 20:29 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-07 4:37 [PATCH 0/8] FPGA DFL Changes for 5.12 Moritz Fischer
2021-01-07 4:37 ` [PATCH 1/8] fpga: dfl: refactor cci_enumerate_feature_devs() Moritz Fischer
2021-01-07 4:37 ` [PATCH 2/8] fpga: dfl-pci: locate DFLs by PCIe vendor specific capability Moritz Fischer
2021-01-07 4:37 ` [PATCH 3/8] fpga: dfl: fix the definitions of type & feature_id for dfl devices Moritz Fischer
2021-01-07 4:37 ` [PATCH 4/8] fpga: dfl: move dfl_device_id to mod_devicetable.h Moritz Fischer
2021-01-07 4:37 ` [PATCH 5/8] fpga: dfl: add dfl bus support to MODULE_DEVICE_TABLE() Moritz Fischer
2021-01-07 4:37 ` [PATCH 6/8] fpga: dfl: move dfl bus related APIs to include/linux/dfl.h Moritz Fischer
2021-01-07 4:37 ` [PATCH 7/8] fpga: dfl: add support for N3000 Nios private feature Moritz Fischer
2021-01-07 4:37 ` [PATCH 8/8] memory: dfl-emif: add the DFL EMIF private feature driver Moritz Fischer
2021-01-07 16:09 ` [PATCH 0/8] FPGA DFL Changes for 5.12 Tom Rix
2021-01-07 16:14 ` Greg KH
2021-01-07 17:01 ` Tom Rix
2021-01-10 15:46 ` Tom Rix
2021-01-10 17:05 ` Moritz Fischer
2021-01-10 19:43 ` Tom Rix
2021-01-11 6:57 ` Greg KH
2021-01-11 14:40 ` Tom Rix
2021-01-11 14:54 ` Greg KH
2021-01-11 15:55 ` Tom Rix
2021-01-11 16:09 ` Greg KH
2021-01-11 16:43 ` Tom Rix
2021-01-11 18:21 ` Greg KH
2021-01-11 19:46 ` Tom Rix
2021-01-11 20:03 ` Greg KH
2021-01-11 20:28 ` Moritz Fischer [this message]
2021-01-11 22:39 ` Tom Rix
2021-01-14 16:48 ` Moritz Fischer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=X/y0+ZCPsfrg/LUp@archbook \
--to=mdf@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-fpga@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=matthew.gerlach@intel.com \
--cc=moritzf@google.com \
--cc=richard.gong@intel.com \
--cc=rikard.falkeborn@gmail.com \
--cc=russell.h.weight@intel.com \
--cc=sonal.santan@xilinx.com \
--cc=trix@redhat.com \
--cc=yilun.xu@intel.com \
--cc=zhengyongjun3@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).