* Re: [Qemu-devel] [PATCH 0/7] cpu model bug fixes and definition corrections
2011-05-23 21:45 [Qemu-devel] [PATCH 0/7] cpu model bug fixes and definition corrections john cooper
@ 2011-05-24 6:58 ` Markus Armbruster
0 siblings, 0 replies; 2+ messages in thread
From: Markus Armbruster @ 2011-05-24 6:58 UTC (permalink / raw)
To: john cooper; +Cc: Anthony Liguori, qemu-devel
john cooper <john.cooper@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
^ permalink raw reply [flat|nested] 2+ messages in thread