2011/8/20 Dan Kegel dank@kegel.com:
2011/8/19 Frédéric Delanoy frederic.delanoy@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