Hi Andi,
On 3/21/24 14:54, Andi Shyti wrote:
so that it's the [RFC v2 ...] the right series... are you sure?
[RESEND v2 RFC ...] -- it's the second resend (thus third send), not the
second RFC (in retrospect I definitely should have used # instead of v)
The order of arrival is:
1. Date: Tue, 19 Mar 2024 16:51:51 -0600
2. Date: Tue, 19 Mar 2024 19:40:51 -0600
3. Date: Tue, 19 Mar 2024 22:19:53 -0600
Anyway, I will take "1" as the good one, being a v2. I will
discard "2" and "3".
Then, please, do not forget next time the patch 0 and the
changelog.
Patch 0 was probably separated by the lack of threading but can be found
here: https://www.spinics.net/lists/linux-i2c/msg68235.html
There is no changelog as there were no changes to the patch content vs.
either of the first two sending attempts; I was only trying a different
way of navigating the minefield of mail agents that make whitespace
changes without my consent. :)
...
Can you please make sure, next time (unless someone asks to
resend them again), that the patches are threaded? You can send
them to yourself first and see if they are really threaded.
Yes, definitely. I take it from your phrasing that you're willing to collect
the scattered mails yourself this one time only? If so, thank you for
cleaning up after my mess. :)
If not (and/or if someone else doesn't like the mess), I can always resend.
I have already made one cleanup (removing the useless `default:` at the end
of the FSM) so I guess it would technically be an "RFC v2" at this point.
For now no need to resend (unless someone complains). Let's give
it some time for review.
Andi
Thanks again,
Sam
