Lines Matching +full:power +full:- +full:stable +full:- +full:time

23 ----------------------
31  - If you have explained your patch well, reviewers will understand its
35    Many of the changes you may be asked to make - from coding style tweaks
36    to substantial rewrites - come from the understanding that Linux will
39  - Code review is hard work, and it is a relatively thankless occupation;
47  - Similarly, code reviewers are not trying to promote their employers'
54  - Be prepared for seemingly silly requests for coding style changes
59    kernel feature ready for next time.
64 from happening.  When you get review comments on a patch, take the time to
75 agree with the reviewer, take some time to think things over again.  It can
82 can help future reviewers avoid the questions which came up the first time
87 responded to the comments you got the time before, you're likely to find
91 going to remember all the details of the code you posted the last time
96 time; if you help them get a running start, they will be in a better mood
103 always try appealing to a higher power.  As of this writing, that higher
104 power tends to be Andrew Morton.  Andrew has a great deal of respect in the
112 -----------------
118 things.  In particular, there may be more than one tree - one, perhaps,
120 longer-term work.
124 being -mm.  Patches which affect multiple subsystems can also end up going
125 through the -mm tree.
129 default.  Subsystem trees typically feed linux-next as well, making their
141 blessings: before the advent of the linux-next tree, these conflicts often
182 reports: the next mainline stable release, when prominent distributors pick
187 after it's merged.  The next time you post a patch, they will be evaluating
193 -----------------------------
200 your own), or send an Acked-by: response back and let the original poster
209 kernel, nobody has absolute veto power over any code.  Except maybe Linus.