Hi Jian, First, thank you for the energy you have been putting into this. The patches you send are good work, and I am not questioning any of it -- I would far rather work with someone who sends too much than with someone who sends nothing.
What I want to raise is not the changes themselves but a practical problem: the rate at which they arrive. Since the start of August you have sent about a dozen patches off-list and a couple on the list. In the same period the posted series has not moved: v50 is still what Tatsuo posted at the end of last month. What is being worked through right now is the code from the July visit -- the fortnight in Korea left a branch dozens of commits ahead of v50, none of it submitted yet. So new patches are arriving faster than that is being resolved, and the queue is growing at the far end, not at yours. What sits at that far end is the part I have to do: rebase each change onto the series, verify it, write the commit message, and post it -- and after that Tatsuo has to be able to apply what he receives. His reply on 08-21 is a symptom of the same thing: v51-0001 is based on our branch, which by now is dozens of commits away from v50, so it could not apply for him at all. Absorbing a refactoring takes me more time than it took to write it. As long as that is the ratio, this patch cannot be brought to an end. What I would like to ask is simple. When the queue has grown past a certain point, please pause new patches and let the back of the pipeline drain before adding to it. It is the same rule we use at work: once we enter the release phase, the quality team works through the modules that have defects, and the developers on the modules without defects do not start anything new -- they wait. Idle time there is not waste; it is what keeps the release from getting further away. Concretely, for now: I would rather you hold new refactoring patches while the ones already submitted are being absorbed. v51-0001 I will fold into the series myself, rebase it and verify it, so nothing you have written is lost. In the meantime, work that does not land on the back of the pipeline is welcome -- standards analysis, or fixes for defects already reported. None of this is about the quality of what you send. It is about the order in which it can be absorbed. Best regards, Henson
