Lines Matching refs:what

109 priority in KVM x86.  If all else fails, match what already exists.
127 what it does.  Do not reiterate what the code literally does; let the code
203 Stating what a patch does before diving into details is preferred by KVM x86
204 for several reasons.  First and foremost, what code is actually being changed
206 find. Changelogs that bury the "what's actually changing" in a one-liner after
209 For initial review, one could argue the "what's broken" is more important, but
212 way are useless, the details only matter for the culprit.  Providing the "what
216 Another benefit of stating "what's changing" first is that it's almost always
217 possible to state "what's changing" in a single sentence.  Conversely, all but
219 the problem.  If both the "what's changing" and "what's the bug" are super
221 "what's changing), then covering the shorter one first is advantageous because
224 painful than having to skip three paragraphs to get to "what's changing".
270 what level of testing you were able to do, e.g. in the cover letter.
291 should clearly state what type of feedback is requested/expected.  Do not abuse
299 readers what is broken and how to verify the fix.  Some leeway is given for