^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 1) .. _development_followthrough:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 2)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 3) Followthrough
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 4) =============
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 5)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 6) At this point, you have followed the guidelines given so far and, with the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 7) addition of your own engineering skills, have posted a perfect series of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 8) patches. One of the biggest mistakes that even experienced kernel
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 9) developers can make is to conclude that their work is now done. In truth,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 10) posting patches indicates a transition into the next stage of the process,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 11) with, possibly, quite a bit of work yet to be done.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 12)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 13) It is a rare patch which is so good at its first posting that there is no
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 14) room for improvement. The kernel development process recognizes this fact,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 15) and, as a result, is heavily oriented toward the improvement of posted
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 16) code. You, as the author of that code, will be expected to work with the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 17) kernel community to ensure that your code is up to the kernel's quality
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 18) standards. A failure to participate in this process is quite likely to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 19) prevent the inclusion of your patches into the mainline.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 20)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 21)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 22) Working with reviewers
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 23) ----------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 24)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 25) A patch of any significance will result in a number of comments from other
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 26) developers as they review the code. Working with reviewers can be, for
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 27) many developers, the most intimidating part of the kernel development
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 28) process. Life can be made much easier, though, if you keep a few things in
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 29) mind:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 30)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 31) - If you have explained your patch well, reviewers will understand its
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 32) value and why you went to the trouble of writing it. But that value
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 33) will not keep them from asking a fundamental question: what will it be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 34) like to maintain a kernel with this code in it five or ten years later?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 35) Many of the changes you may be asked to make - from coding style tweaks
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 36) to substantial rewrites - come from the understanding that Linux will
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 37) still be around and under development a decade from now.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 38)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 39) - Code review is hard work, and it is a relatively thankless occupation;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 40) people remember who wrote kernel code, but there is little lasting fame
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 41) for those who reviewed it. So reviewers can get grumpy, especially when
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 42) they see the same mistakes being made over and over again. If you get a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 43) review which seems angry, insulting, or outright offensive, resist the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 44) impulse to respond in kind. Code review is about the code, not about
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 45) the people, and code reviewers are not attacking you personally.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 46)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 47) - Similarly, code reviewers are not trying to promote their employers'
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 48) agendas at the expense of your own. Kernel developers often expect to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 49) be working on the kernel years from now, but they understand that their
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 50) employer could change. They truly are, almost without exception,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 51) working toward the creation of the best kernel they can; they are not
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 52) trying to create discomfort for their employers' competitors.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 53)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 54) What all of this comes down to is that, when reviewers send you comments,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 55) you need to pay attention to the technical observations that they are
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 56) making. Do not let their form of expression or your own pride keep that
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 57) from happening. When you get review comments on a patch, take the time to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 58) understand what the reviewer is trying to say. If possible, fix the things
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 59) that the reviewer is asking you to fix. And respond back to the reviewer:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 60) thank them, and describe how you will answer their questions.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 61)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 62) Note that you do not have to agree with every change suggested by
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 63) reviewers. If you believe that the reviewer has misunderstood your code,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 64) explain what is really going on. If you have a technical objection to a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 65) suggested change, describe it and justify your solution to the problem. If
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 66) your explanations make sense, the reviewer will accept them. Should your
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 67) explanation not prove persuasive, though, especially if others start to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 68) agree with the reviewer, take some time to think things over again. It can
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 69) be easy to become blinded by your own solution to a problem to the point
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 70) that you don't realize that something is fundamentally wrong or, perhaps,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 71) you're not even solving the right problem.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 72)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 73) Andrew Morton has suggested that every review comment which does not result
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 74) in a code change should result in an additional code comment instead; that
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 75) can help future reviewers avoid the questions which came up the first time
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 76) around.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 77)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 78) One fatal mistake is to ignore review comments in the hope that they will
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 79) go away. They will not go away. If you repost code without having
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 80) responded to the comments you got the time before, you're likely to find
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 81) that your patches go nowhere.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 82)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 83) Speaking of reposting code: please bear in mind that reviewers are not
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 84) going to remember all the details of the code you posted the last time
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 85) around. So it is always a good idea to remind reviewers of previously
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 86) raised issues and how you dealt with them; the patch changelog is a good
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 87) place for this kind of information. Reviewers should not have to search
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 88) through list archives to familiarize themselves with what was said last
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 89) time; if you help them get a running start, they will be in a better mood
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 90) when they revisit your code.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 91)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 92) What if you've tried to do everything right and things still aren't going
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 93) anywhere? Most technical disagreements can be resolved through discussion,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 94) but there are times when somebody simply has to make a decision. If you
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 95) honestly believe that this decision is going against you wrongly, you can
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 96) always try appealing to a higher power. As of this writing, that higher
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 97) power tends to be Andrew Morton. Andrew has a great deal of respect in the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 98) kernel development community; he can often unjam a situation which seems to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 99) be hopelessly blocked. Appealing to Andrew should not be done lightly,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 100) though, and not before all other alternatives have been explored. And bear
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 101) in mind, of course, that he may not agree with you either.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 102)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 103)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 104) What happens next
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 105) -----------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 106)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 107) If a patch is considered to be a good thing to add to the kernel, and once
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 108) most of the review issues have been resolved, the next step is usually
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 109) entry into a subsystem maintainer's tree. How that works varies from one
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 110) subsystem to the next; each maintainer has his or her own way of doing
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 111) things. In particular, there may be more than one tree - one, perhaps,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 112) dedicated to patches planned for the next merge window, and another for
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 113) longer-term work.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 114)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 115) For patches applying to areas for which there is no obvious subsystem tree
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 116) (memory management patches, for example), the default tree often ends up
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 117) being -mm. Patches which affect multiple subsystems can also end up going
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 118) through the -mm tree.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 119)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 120) Inclusion into a subsystem tree can bring a higher level of visibility to a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 121) patch. Now other developers working with that tree will get the patch by
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 122) default. Subsystem trees typically feed linux-next as well, making their
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 123) contents visible to the development community as a whole. At this point,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 124) there's a good chance that you will get more comments from a new set of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 125) reviewers; these comments need to be answered as in the previous round.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 126)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 127) What may also happen at this point, depending on the nature of your patch,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 128) is that conflicts with work being done by others turn up. In the worst
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 129) case, heavy patch conflicts can result in some work being put on the back
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 130) burner so that the remaining patches can be worked into shape and merged.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 131) Other times, conflict resolution will involve working with the other
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 132) developers and, possibly, moving some patches between trees to ensure that
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 133) everything applies cleanly. This work can be a pain, but count your
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 134) blessings: before the advent of the linux-next tree, these conflicts often
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 135) only turned up during the merge window and had to be addressed in a hurry.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 136) Now they can be resolved at leisure, before the merge window opens.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 137)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 138) Some day, if all goes well, you'll log on and see that your patch has been
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 139) merged into the mainline kernel. Congratulations! Once the celebration is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 140) complete (and you have added yourself to the MAINTAINERS file), though, it
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 141) is worth remembering an important little fact: the job still is not done.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 142) Merging into the mainline brings its own challenges.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 143)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 144) To begin with, the visibility of your patch has increased yet again. There
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 145) may be a new round of comments from developers who had not been aware of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 146) the patch before. It may be tempting to ignore them, since there is no
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 147) longer any question of your code being merged. Resist that temptation,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 148) though; you still need to be responsive to developers who have questions or
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 149) suggestions.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 150)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 151) More importantly, though: inclusion into the mainline puts your code into
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 152) the hands of a much larger group of testers. Even if you have contributed
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 153) a driver for hardware which is not yet available, you will be surprised by
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 154) how many people will build your code into their kernels. And, of course,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 155) where there are testers, there will be bug reports.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 156)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 157) The worst sort of bug reports are regressions. If your patch causes a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 158) regression, you'll find an uncomfortable number of eyes upon you;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 159) regressions need to be fixed as soon as possible. If you are unwilling or
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 160) unable to fix the regression (and nobody else does it for you), your patch
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 161) will almost certainly be removed during the stabilization period. Beyond
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 162) negating all of the work you have done to get your patch into the mainline,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 163) having a patch pulled as the result of a failure to fix a regression could
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 164) well make it harder for you to get work merged in the future.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 165)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 166) After any regressions have been dealt with, there may be other, ordinary
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 167) bugs to deal with. The stabilization period is your best opportunity to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 168) fix these bugs and ensure that your code's debut in a mainline kernel
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 169) release is as solid as possible. So, please, answer bug reports, and fix
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 170) the problems if at all possible. That's what the stabilization period is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 171) for; you can start creating cool new patches once any problems with the old
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 172) ones have been taken care of.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 173)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 174) And don't forget that there are other milestones which may also create bug
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 175) reports: the next mainline stable release, when prominent distributors pick
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 176) up a version of the kernel containing your patch, etc. Continuing to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 177) respond to these reports is a matter of basic pride in your work. If that
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 178) is insufficient motivation, though, it's also worth considering that the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 179) development community remembers developers who lose interest in their code
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 180) after it's merged. The next time you post a patch, they will be evaluating
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 181) it with the assumption that you will not be around to maintain it
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 182) afterward.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 183)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 184)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 185) Other things that can happen
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 186) -----------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 187)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 188) One day, you may open your mail client and see that somebody has mailed you
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 189) a patch to your code. That is one of the advantages of having your code
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 190) out there in the open, after all. If you agree with the patch, you can
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 191) either forward it on to the subsystem maintainer (be sure to include a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 192) proper From: line so that the attribution is correct, and add a signoff of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 193) your own), or send an Acked-by: response back and let the original poster
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 194) send it upward.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 195)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 196) If you disagree with the patch, send a polite response explaining why. If
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 197) possible, tell the author what changes need to be made to make the patch
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 198) acceptable to you. There is a certain resistance to merging patches which
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 199) are opposed by the author and maintainer of the code, but it only goes so
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 200) far. If you are seen as needlessly blocking good work, those patches will
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 201) eventually flow around you and get into the mainline anyway. In the Linux
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 202) kernel, nobody has absolute veto power over any code. Except maybe Linus.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 203)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 204) On very rare occasion, you may see something completely different: another
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 205) developer posts a different solution to your problem. At that point,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 206) chances are that one of the two patches will not be merged, and "mine was
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 207) here first" is not considered to be a compelling technical argument. If
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 208) somebody else's patch displaces yours and gets into the mainline, there is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 209) really only one way to respond: be pleased that your problem got solved and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 210) get on with your work. Having one's work shoved aside in this manner can
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 211) be hurtful and discouraging, but the community will remember your reaction
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 212) long after they have forgotten whose patch actually got merged.
Orange Pi5 kernel
Deprecated Linux kernel 5.10.110 for OrangePi 5/5B/5+ boards
3 Commits
0 Branches
0 Tags