[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8c81f173-88da-64e6-69e1-bf824b3a99ab@gmail.com>
Date: Tue, 7 Sep 2021 07:35:09 +0200
From: Rafał Miłecki <zajec5@...il.com>
To: Jakub Kicinski <kuba@...nel.org>, Andrew Lunn <andrew@...n.ch>
Cc: Florian Fainelli <f.fainelli@...il.com>,
patchwork-bot+netdevbpf@...nel.org, vivien.didelot@...il.com,
olteanv@...il.com, davem@...emloft.net, netdev@...r.kernel.org,
rafal@...ecki.pl
Subject: Re: [PATCH] net: dsa: b53: Fix IMP port setup on BCM5301x
On 07.09.2021 03:48, Jakub Kicinski wrote:
> On Mon, 6 Sep 2021 02:48:34 +0200 Andrew Lunn wrote:
>>> not allowing a proper review to happen. So please, I am begging you, wait at
>>> least 12h, ideally 24h before applying a patch.
>
> The fixed wait time before applying would likely require more nuance.
> For example something like 0h for build fixed; 12h if reviewed by all
> area experts; 24h+ for the rest? Not counting weekends?
As a maintainer I'd probably prefer 48 hours with 24 h being a minimum.
>> 24 hours is too short. We all have lives outside of the kernel. I
>> found the older policy of 3 days worked well. Enough time for those
>> who had interest to do a review, but short enough to not really slow
>> down development. And 3 days is still probably faster than any other
>> subsystem.
>
> It is deeply unsatisfying tho to be waiting for reviews 3 days, ping
> people and then have to apply the patch anyway based on one's own
> judgment. I personally dislike the uncertainty of silently waiting.
> I have floated the idea before, perhaps it's not taken seriously given
> speed of patchwork development, but would it be okay to have a strict
> time bound and then require people to mark patches in patchwork as
> "I'm planning to review this"?
>
> Right now we make some attempts to delegate to "Needs ACK" state but
> with mixed result (see the two patches hanging in that state now).
>
> Perhaps the "Plan to review" marking in pw is also putting the cart
> before the horse (quite likely, knowing my project management prowess.)
> Either way if we're expending brain cycles on process changes it would
> be cool to think more broadly than just "how long to set a timer for".
"Needs ACK" sounds good for a state where net maintainers need code
maintainer ack/review.
Do you already have some special meaning for the "Under Review"? That
sounds (compared to the "New") like someone actually planning to (n)ack
a patch.
Powered by blists - more mailing lists