john cooper <john.coo...@redhat.com> writes: > This series is a resend of several pending patches which > have been brought up-to-date. All address problems we have > found and corrected in our codebase in the process of test > and deploy of cpu model support. > > A few have been modified slightly to address minor whitespace > issues and 4/7 reverts the cli syntax for the proposed option > to the original submission in order to preserve the established > CLI interface. > > Please review and apply.
Two annoying nits: * The patches are not threaded together with In-Reply-To headers. git-send-email recommended. * The Subject: lines could use some love. They should be a summary of the patch, distinct, and not too long. Yours either aren't distinct, or much too long: [PATCH 0/7] cpu model bug fixes and definition corrections [PATCH 1/7] cpu model bug fixes and definition corrections: Correct archaic CPU model "model" field for Intel CPUs. [PATCH 2/7] cpu model bug fixes and definition corrections: Allow an optional qemu_early_init_vcpu() [PATCH 3/7] cpu model bug fixes and definition corrections: Add kvm emulated x2apic flag to config defined cpu models [PATCH 4/7] cpu model bug fixes and definition corrections [PATCH 5/7] cpu model bug fixes and definition corrections [PATCH 6/7] cpu model bug fixes and definition corrections [PATCH 7/7] cpu model bug fixes and definition corrections See appendix for more on proper patch subjects. Should be easy enough to fix :) Appendix: from linux-2.6.linus/Documentation/SubmittingPatches The canonical patch subject line is: Subject: [PATCH 001/123] subsystem: summary phrase [...] The Subject line format makes it very easy to sort the emails alphabetically by subject line - pretty much any email reader will support that - since because the sequence number is zero-padded, the numerical and alphabetic sort is the same. The "subsystem" in the email's Subject should identify which area or subsystem of the kernel is being patched. The "summary phrase" in the email's Subject should concisely describe the patch which that email contains. The "summary phrase" should not be a filename. Do not use the same "summary phrase" for every patch in a whole patch series (where a "patch series" is an ordered sequence of multiple, related patches). Bear in mind that the "summary phrase" of your email becomes a globally-unique identifier for that patch. It propagates all the way into the git changelog. The "summary phrase" may later be used in developer discussions which refer to the patch. People will want to google for the "summary phrase" to read discussion regarding that patch. It will also be the only thing that people may quickly see when, two or three months later, they are going through perhaps thousands of patches using tools such as "gitk" or "git log --oneline". For these reasons, the "summary" must be no more than 70-75 characters, and it must describe both what the patch changes, as well as why the patch might be necessary. It is challenging to be both succinct and descriptive, but that is what a well-written summary should do. The "summary phrase" may be prefixed by tags enclosed in square brackets: "Subject: [PATCH tag] <summary phrase>". The tags are not considered part of the summary phrase, but describe how the patch should be treated. Common tags might include a version descriptor if the multiple versions of the patch have been sent out in response to comments (i.e., "v1, v2, v3"), or "RFC" to indicate a request for comments. If there are four patches in a patch series the individual patches may be numbered like this: 1/4, 2/4, 3/4, 4/4. This assures that developers understand the order in which the patches should be applied and that they have reviewed or applied all of the patches in the patch series. A couple of example Subjects: Subject: [patch 2/5] ext2: improve scalability of bitmap searching Subject: [PATCHv2 001/207] x86: fix eflags tracking