Mauerer runbapp06.tex V1 - 09/04/2008 6:14pm Page 1280
Appendix F: The Kernel Development Process
source works better than their five engineers do. They’ve apparently made
a couple of outlandish claims about where our source code comes from,
including claiming to own code that was clearly written by me over a
decade ago.
In fact, this case is mostly history now, and people (with the possible exception of the CEO of the afore-
mentioned company) are universally convinced that a simple first-fit allocator whose copyright youmight
possibly own is not quite a completeUnixkernel...Nevertheless, thanks toSigned-off-bytags, it is
now possible to precisely identify who wrote which patch.
There are also two weaker forms of marking patches:
❑ Acked-bymeans that a developer is not directly involved with the patch, but nevertheless deems
it correct after some review.
This does not necessarily imply that the ACK-ing developer has worked through the
completepatch, but may just indicate compliance with the parts that touch the
respective field of competence.
If, for instance, an architecture maintainer acknowledges a patch that looks fine with
respect to all changes performed in thearch/xyzdirectory, but that also contains
code infs/that fries all strings composed of an odd number of chars in files that
start with an M, you cannot blame the ACK-ing developer for this.
However, it’s highly unlikely that this will ever happen, because architecture
maintainers are all very good at what they do, and would detect the subversive
wickedness of the patch already by the smell of the file — this example just serves to
explain the concept.
❑ CCis used to signify that a person has at least been informed about the patch, so he should
theoretically be aware of the patch’s existence, and had a chance to object.
During the development of kernel 2.6.25, a discussion arose, about the value of code review and how
credit should be given to reviewers and one solution to which people agreed was to introduce the
Reviewed-Bypatch tag. The tag states the following:
Documentation/SubmittingPatches
Reviewer’s statement of oversight
By offering my Reviewed-by: tag, I state that:
(a) I have carried out a technical review of this patch to
evaluate its appropriateness and readiness for inclusion into
the mainline kernel.
(b) Any problems, concerns, or questions relating to the patch
have been communicated back to the submitter. I am satisfied
with the submitter’s response to my comments.
(c) While there may be things that could be improved with this
submission, I believe that it is, at this time, (1) a
worthwhile modification to the kernel, and (2) free of known
issues which would argue against its inclusion.
