Re: Row pattern recognition

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