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

9 developers can make is to conclude that their work is now done.  In truth,
13 It is a rare patch which is so good at its first posting that there is no
15 and, as a result, is heavily oriented toward the improvement of posted
17 kernel community to ensure that your code is up to the kernel's quality
18 standards.  A failure to participate in this process is quite likely to
39  - Code review is hard work, and it is a relatively thankless occupation;
40    people remember who wrote kernel code, but there is little lasting fame
44    impulse to respond in kind.  Code review is about the code, not about
56    the kernel. One job the maintainers do is to keep things looking
61 What all of this comes down to is that, when reviewers send you comments,
65 understand what the reviewer is trying to say.  If possible, fix the things
66 that the reviewer is asking you to fix.  And respond back to the reviewer:
71 explain what is really going on.  If you have a technical objection to a
77 that you don't realize that something is fundamentally wrong or, perhaps,
85 One fatal mistake is to ignore review comments in the hope that they will
92 around.  So it is always a good idea to remind reviewers of previously
93 raised issues and how you dealt with them; the patch changelog is a good
102 honestly believe that this decision is going against you wrongly, you can
114 If a patch is considered to be a good thing to add to the kernel, and once
115 most of the review issues have been resolved, the next step is usually
119 dedicated to patches planned for the next merge window, and another for
122 For patches applying to areas for which there is no obvious subsystem tree
135 is that conflicts with work being done by others turn up.  In the worst
142 only turned up during the merge window and had to be addressed in a hurry.
143 Now they can be resolved at leisure, before the merge window opens.
146 merged into the mainline kernel.  Congratulations!  Once the celebration is
148 is worth remembering an important little fact: the job still is not done.
153 the patch before.  It may be tempting to ignore them, since there is no
160 a driver for hardware which is not yet available, you will be surprised by
174 bugs to deal with.  The stabilization period is your best opportunity to
176 release is as solid as possible.  So, please, answer bug reports, and fix
177 the problems if at all possible.  That's what the stabilization period is
184 respond to these reports is a matter of basic pride in your work.  If that
185 is insufficient motivation, though, it's also worth considering that the
187 after it's merged.  The next time you post a patch, they will be evaluating
196 a patch to your code.  That is one of the advantages of having your code
199 proper From: line so that the attribution is correct, and add a signoff of
205 acceptable to you.  There is a certain resistance to merging patches which
214 here first" is not considered to be a compelling technical argument.  If
215 somebody else's patch displaces yours and gets into the mainline, there is