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  linux-cve-announce  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]
Message-ID: <88954576-5e62-4d95-bdf4-3913ffea68c2@schaufler-ca.com>
Date: Tue, 8 Oct 2024 11:25:16 -0700
From: Casey Schaufler <casey@...aufler-ca.com>
To: "Dr. Greg" <greg@...ellic.com>, Paul Moore <paul@...l-moore.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
 Jonathan Corbet <corbet@....net>,
 Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
 LKML <linux-kernel@...r.kernel.org>, linux-security-module@...r.kernel.org,
 Casey Schaufler <casey@...aufler-ca.com>
Subject: Re: [GIT PULL] tomoyo update for v6.12

On 10/8/2024 4:14 AM, Dr. Greg wrote:
> ...
>
> Which we also believe justifies more attention than what it has been
> able to receive in 20 months.

You're right. You're also not alone. There are things that you can do
that will help get the review you're looking for. Developers who attend
to the needs and preferences of reviewers get a whole lot more attention
than those who fuss and fume about not getting what they "deserve". My
hopefully constructive recommendations are:

1.	Lead with code. Save the documentation for later.
2.	Incremental implementation. Don't drop the whole mess on the
	reviewers at once. A patch set should be a story, with each patch
	introducing one new element.
3.	Emphasize the similarities with existing implementations. No one
	wants to deal with novel or clever code. If it is familiar, it is
	easy to understand.
4.	Thank your reviewers. Complaints about review latency typically
	increase it.
5.	Do some reviews yourself. That will get in the good graces of other
	reviewers.
6.	Be brief. The biggest single problem with reviewing TSEM has been that
	doing anything takes so long. Multiple paragraph responses to an issue
	don't help. Say it, say it once, say it in small words, and use as
	few of those as possible.




Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ