[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20120723.144421.1741050474189216927.davem@davemloft.net>
Date: Mon, 23 Jul 2012 14:44:21 -0700 (PDT)
From: David Miller <davem@...emloft.net>
To: or.gerlitz@...il.com
Cc: klebers@...ux.vnet.ibm.com, ogerlitz@...lanox.com,
netdev@...r.kernel.org, jackm@....mellanox.co.il,
yevgenyp@...lanox.co.il, cascardo@...ux.vnet.ibm.com,
brking@...ux.vnet.ibm.com, shlomop@...lanox.com
Subject: Re: [PATCH] mlx4: Add support for EEH error recovery
From: Or Gerlitz <or.gerlitz@...il.com>
Date: Tue, 24 Jul 2012 00:42:08 +0300
> On Tue, Jul 24, 2012 at 12:34 AM, David Miller <davem@...emloft.net> wrote:
>
>> Can we please move forward, if he implemented the feature properly
>> and he tested it successfully, unless you can find a logic or
>> stylistic flaw in his patch please ACK it.
>>
>> You can't hold his changes back while you work out how _YOU_ can
>> test it to your liking.
>
> Hi Dave,
>
> We're trying to act in R/R (Responsive and Responsible) manner -
> namely Shlomo did code review of the patches and we want to further
> evaluate them by testing, I think its fully legitimate to test a patch
> before ACK-ing. Doing these types of tests isn't around my personal
> typical daily menu and I'm asking for some directives from the author
> on how to issue that testing, I don't see what wrong here. We're
> planning anyway to go deeper around this area and enhance the PCI
> hotplug /error handling related code in the driver, so there's an
> initial learing curve here, makes sense? we can move the Q&A for the
> testing to be off-list if you prefer it to go that way.
But ACK his patch, because you have not found any problems with it.
This is taking days, and you're stalling further progress.
I never let patches rot in patchwork more than a few days, as this
patch has already.
Either ACK or provide a legitimate reason to reject it now.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists