Lines Matching refs:t

26      - Code that doesn't pass review will not get merged. See :ref:`participating_in_code_review`
71 won't even apply to master. We only apply selected bugfixes to release
87 Each change should compile and execute successfully. For instance, don't
91 points in the commit history where QEMU doesn't work for reasons
126 to focus on the few changes that weren't wholesale code motion.
130 Don't include irrelevant changes
133 In particular, don't include formatting, coding style or whitespace
138 as a separate patch which makes no semantic changes; don't put it in the
165 change is important. Don't include comments like "This is a suggestion
167 they don't go into the final commit message). Make sure the body of the
203 is such a large project the default configuration won't create a
209 don't normally experiment with. See :ref:`testing` for more details on
213 your patches - either to ensure that future changes won't regress your
218 bisection doesn't land on a known-broken state.
361 When reviewers don't know your goal at the start of their review, they
362 may object to early changes that don't make sense until the end of the
365 number of review-fix cycles because the reviewers haven't bought into
380 "RFC" means "Request For Comments" and is a statement that you don't
384 -  the patch depends on some pending kernel changes which haven't yet
387 -  the patch set is not finished yet (perhaps it doesn't cover all use
392 patchset that the submitter themselves is saying shouldn't be applied,
442 if you don't do it then your changes will never get into QEMU.
465 patch. Reviewers aren't always perfect, so it is okay if you want to
477 fresh email or series of emails -- don't try to make it a followup to
491 patch, you resend the entire series and mark it as "v2". Don't try to
534 whitespace, that doesn't affect code content). You should then update
596 from others as what you submit. Don't worry if you don't know the code