[PATCH 01/10] cmd: Use CSTR_* instead of hardcoded values as result of CompareStringW

[Frédéric Delanoy]

2011/8/20 Dan Kegel <dank at kegel.com>:
> 2011/8/19 Frédéric Delanoy <frederic.delanoy at gmail.com>:
>> The last [10/10] patch was the cause. I sent an updated version.
>
> Hmm.  You sent 10/10 before 1/10.

Yeah, I thought it was sufficient, but testbot choked on it and waited
for the remaining patches in the series.

> My patch series recognizer
> rejected the series.  It would be hard to fix.  Let's see if we can
> live with the rule "patch series must be sent in order".
>
>> I wonder how/whether the various (resend) or (try N) are handled for
>> revised patch series
>
> My recognizer does not notice those designations, nor the time or
> order of arrival.
> It only looks at the 'Date:' and 'From:' fields, and the '[%d/%d]'
> part of the subject line.
> (The exact regular expression I use is \[\D*(\d+)/(\d+)\D*\] .)

Using the dates of the git format-patches can be problematic, e.g.
when you local git branch has been modified before submission (think
rebase -i)

> Humans prefer (resend) for unchanged resends, and (try N+1) for
> changed resends, I think.

As I said, I have sent an updated/fixed version of the [10/10]. Then
(for the unchanged one) [1/10] <...> (resend) (try 2) ... [9/10] <...>
(resend) (try 2) once I saw testbot was waiting for the rest of the
series, which it processed afterwards

IIRC someone told me some time ago to resent the whole series with
(try N+1) for tests processed by testbot. The (resend) is just a hint
to AJ that that very patch hasn't been revised, just regenerated.

IMHO your patch series recognizer should use the same strategy as
testbot, for consistency, and wait for the whole series to be
available before processing can start.

Frédéric