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:   Tue, 7 Sep 2021 07:35:09 +0200
From:   Rafał Miłecki <>
To:     Jakub Kicinski <>, Andrew Lunn <>
Cc:     Florian Fainelli <>,,,,,,
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