Lines Matching +refs:is +refs:post +refs:merge

18 Testing is mandatory.  Be consistent with established styles and patterns.
22 KVM x86 is currently in a transition period from being part of the main KVM
23 tree, to being "just another KVM arch".  As such, KVM x86 is split across the
28 main KVM tree, while all development for the next cycle is routed through the
29 KVM x86 tree.  In the unlikely event that a fix for the current cycle is routed
33 Note, this transition period is expected to last quite some time, i.e. will be
38 The KVM x86 tree is organized into multiple topic branches.  The purpose of
39 using finer-grained topic branches is to make it easier to keep tabs on an area
46 via a Cthulhu merge on an as-needed basis, i.e. when a topic branch is updated.
56 typically the week before Linus' opening of the merge window, e.g. the week
58 rolled into the main KVM pull request sent during Linus' merge window.
60 The KVM x86 tree doesn't have its own official merge window, but there's a soft
72 Note, the vast majority of review is done between rc1 and rc6, give or take.
73 The period between rc6 and the next rc1 is used to catch up on other tasks,
89 automatically warrant inclusion in the current release.  There is no singular
93 Everything else should be based on ``kvm-x86/next``, i.e. there is no need to
95 dependencies across topic branches, it is the maintainer's job to sort them
98 The only exception to using ``kvm-x86/next`` as the base is if a patch/series
99 is a multi-arch series, i.e. has non-trivial modifications to common KVM code
102 history, e.g. the release candidate upon which ``kvm-x86 next`` is based.  If
103 you're unsure whether a patch/series is truly multi-arch, err on the side of
108 When it comes to style, naming, patterns, etc., consistency is the number one
116 variable declarations isn't strictly required, though it is still preferred.
128 speak for itself.  If the code itself is inscrutable, comments will not help.
132 Much of KVM's code base is directly tied to architectural behavior defined in
135 "APM", without additional context is a-ok.
144 therefore it's implied that KVM behavior is emulating SDM and/or APM behavior.
146 context is perfectly ok and encouraged.
150 The preferred prefix format is ``KVM: <topic>:``, where ``<topic>`` is one of::
162 **DO NOT use x86/kvm!**  ``x86/kvm`` is used exclusively for Linux-as-a-KVM-guest
169 All names are case sensitive!  ``KVM: x86:`` is good, ``kvm: vmx:`` is not.
181 first common parent (which is often simply ``x86``).  When in doubt,
201 that primarily target arch/x86 code that is _NOT_ KVM 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
205 is arguably the most important information, and so that info should be easy to
209 For initial review, one could argue the "what's broken" is more important, but
216 Another benefit of stating "what's changing" first is that it's almost always
220 short then the order doesn't matter.  But if one is shorter (almost always the
221 "what's changing), then covering the shorter one first is advantageous because
223 preference.  E.g. having to skip one sentence to get to the context is less
239 When a function is mentioned in a comment, changelog, or shortlog (or anywhere
250 Running KVM selftests and KVM-unit-tests is also mandatory (and stating the
251 obvious, the tests need to pass).  The only exception is for changes that have
253 modify comments.  When possible and relevant, testing on both Intel and AMD is
254 strongly preferred.  Booting an actual VM is encouraged, but not mandatory.
257 disabled is mandatory.  For changes that affect common KVM MMU code, running
258 with TDP disabled is strongly encouraged.  For all other changes, if the code
260 the relevant settings is mandatory.
263 a failure is not due to your changes, verify that the *exact same* failure
275 tests aren't strictly required, e.g. if coverage is provided by running a
281 The only exception to this rule is if KVM is simply advertising support for a
283 can't prevent a guest from using and for which there is no true enabling.
289 Posting new feature development without tests to get early feedback is more
291 should clearly state what type of feedback is requested/expected.  Do not abuse
297 reproducer for the bug being fixed.  In many cases the reproducer is implicit,
299 readers what is broken and how to verify the fix.  Some leeway is given for
301 tests for such bugs is strongly preferred.
303 In general, regression tests are preferred for any bug that is not trivial to
309 if a bug is really truly the end of the world before posting a fix without a
320 is useless for anyone that doesn't have the original message, e.g. if someone
326 a Link: in the changelog as there is no need to record the history in git, i.e.
329 context of why a change was made is highly valuable for future readers.
333 If you are using git version 2.9.0 or later (Googlers, this is all of you!),
337 Note, ``--base=auto`` works as expected if and only if a branch's upstream is
339 is set to your personal repository for backup purposes.  An alternative "auto"
340 solution is to derive the names of your development branches based on their
343 to yield ``--base=x/pmu``, where ``x`` is whatever name your repository uses to
355 know that KVM-unit-tests is a separate repository and get confused when patches
357 KVM patches, first post the KVM changes and then provide a lore Link: to the
362 When a patch/series is officially accepted, a notification email will be sent
367 If a subset of patches is applied, this will be clearly stated in the
372 If for some reason a patch is dropped after officially being accepted, a reply
379 SHA1 is *usually* stable once a notification has been sent, but things happen.