Thread (12 messages) flat view 12 messages, 5 authors, 2021-09-07

Re: [PATCH] net: dsa: b53: Fix IMP port setup on BCM5301x

From: Jakub Kicinski <kuba@kernel.org>
Date: 2021-09-07 01:48:41

On Mon, 6 Sep 2021 02:48:34 +0200 Andrew Lunn wrote:
quoted
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?
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".
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help