linux-fpga.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tom Rix <trix@redhat.com>
To: Moritz Fischer <mdf@kernel.org>
Cc: Greg KH <gregkh@linuxfoundation.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 14:39:36 -0800	[thread overview]
Message-ID: <ac1fd7f4-f53a-ddc4-192b-8c8af254f7ee@redhat.com> (raw)
In-Reply-To: <X/y0+ZCPsfrg/LUp@archbook>


On 1/11/21 12:28 PM, Moritz Fischer wrote:
> 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 ...

Sorry about that.

I really do want to help out, earlier you mentioned patchwork problems.

If you can point me at the wreckage, I'll take a look.

Tom


>
> - Moritz
>


  reply	other threads:[~2021-01-11 22:41 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
2021-01-11 22:39                           ` Tom Rix [this message]
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=ac1fd7f4-f53a-ddc4-192b-8c8af254f7ee@redhat.com \
    --to=trix@redhat.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-fpga@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matthew.gerlach@intel.com \
    --cc=mdf@kernel.org \
    --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=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).