[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210906184838.2ebf3dd3@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
Date: Mon, 6 Sep 2021 18:48:38 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Andrew Lunn <andrew@...n.ch>
Cc: Florian Fainelli <f.fainelli@...il.com>,
patchwork-bot+netdevbpf@...nel.org,
Rafał Miłecki <zajec5@...il.com>,
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 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?
> 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".
Powered by blists - more mailing lists