[<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