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'
57 from happening.  When you get review comments on a patch, take the time to
68 agree with the reviewer, take some time to think things over again.  It can
75 can help future reviewers avoid the questions which came up the first time
80 responded to the comments you got the time before, you're likely to find
84 going to remember all the details of the code you posted the last time
89 time; if you help them get a running start, they will be in a better mood
96 always try appealing to a higher power.  As of this writing, that higher
97 power tends to be Andrew Morton.  Andrew has a great deal of respect in the
105 -----------------
111 things.  In particular, there may be more than one tree - one, perhaps,
113 longer-term work.
117 being -mm.  Patches which affect multiple subsystems can also end up going
118 through the -mm tree.
122 default.  Subsystem trees typically feed linux-next as well, making their
134 blessings: before the advent of the linux-next tree, these conflicts often
175 reports: the next mainline stable release, when prominent distributors pick
180 after it's merged.  The next time you post a patch, they will be evaluating
186 -----------------------------
193 your own), or send an Acked-by: response back and let the original poster
202 kernel, nobody has absolute veto power over any code.  Except maybe Linus.