applied comments by Jan to the HOWTO file

1 files changed, 19 insertions, 13 deletions

diff --git a/HOWTO b/HOWTO
index b07592daf3109c..beb2357c23cc14 100644
--- a/HOWTO
+++ b/HOWTO
@@ -248,8 +248,8 @@ do to try to avoid problems:
     - "Here is my 1000 page design document that describes my idea"
     - "I've been working on this for 6 months..."
     - "Here's a 5000 line patch that..."
-    - "I rewrote all of the current mess, and here it is ..."
-    - "I have a deadline, until that patch needs to be applied."
+    - "I rewrote all of the current mess, and here it is..."
+    - "I have a deadline, and this patch needs to be applied now."
 
 Another way the kernel community is different than most traditional
 software engineering work environments is the faceless nature of
@@ -302,22 +302,28 @@ The reasons for breaking things up are the following:
 2) It's important not only to send small patches, but also to rewrite
    and simplify (or simply re-order) patches before submitting them.
 
-Think of a teacher grading homework from a math student.  The teacher
-does not want to see the student's trials and errors before they came up
-with the solution. They want to see the cleanest, most elegant answer.
-A good student knows this, and would never submit her intermediate work
-before the final solution.
+Here is an analogy from kernel developer Al Viro:
+	"Think of a teacher grading homework from a math student.  The
+	teacher does not want to see the student's trials and errors
+	before they came up with the solution. They want to see the
+	cleanest, most elegant answer.  A good student knows this, and
+	would never submit her intermediate work before the final
+	solution."
 
-The same is true of kernel development. The maintainers and reviewers do
-not want to see the thought process behind the solution to the problem
-one is solving. They want to see a simple and elegant solution.
+	The same is true of kernel development. The maintainers and
+	reviewers do not want to see the thought process behind the
+	solution to the problem one is solving. They want to see a
+	simple and elegant solution."
 
 That may be challenging to keep the balance between presenting an elegant
 solution and working together with the community and discuss your
 unfinished work. Therefore it is good to get early in the process to
 get feedback to improve your work, but also keep your changes in small
 chunks that they may get already accepted, even when your whole task is
-not ready for inclusion now.
+not ready for inclusion now.  
+
+Also realize that it is not acceptable to send patches for inclusion
+that are unfinished and will be "fixed up later."
 
 These things are sometimes very hard to do. It can take years
 to perfect these practices (if at all). It's a continuous process of
@@ -331,8 +337,8 @@ start exactly where you are now.
 ----------
 Thanks to Randy Dunlap and Gerrit Huizenga for the list of things you
 should and should not say.  Also thanks to Pat Mochel, Hanna Linder,
-Randy Dunlap, Kay Sievers and Vojtech Pavlik for their review and
-comments on early drafts of this document.
+Randy Dunlap, Kay Sievers, Vojtech Pavlik, and Jan Kara for their review
+and comments on early drafts of this document.