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
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 6 Sep 2021 18:48:38 -0700
From:   Jakub Kicinski <>
To:     Andrew Lunn <>
Cc:     Florian Fainelli <>,,
        Rafał Miłecki <>,,,,,
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