lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
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