I think I understand this now, and it is ok by me, if the line Commit appears in a message which is telling us a commit happened. I think it is important that we know if a patch has been committed.
I tend to get the mail from the SVN daemon earlier than the one from the discussion list, but yeah, it's good to end a mail thread with "committed as rNNN".
There have been some big patches lately that were in an undertermined state because they got signed off, and acked, and never committed, and i could not tell what had happened.
The way it's done on most GNU projects (that I know off anyway), is that patches from "outsiders" get committed by whomever acks it (and you don't need to do a separate mail saying "ack", you just reply "thanks, commited"), and patches from "insiders" are normally committed by the submitter of the patch. LinuxBIOS might want to do something similar.
So if you have a thread, and you see signed-off and acked lines, but no commit lines, you can assume the patch was not committed. Right now, you just can not tell.
So if you signed off a patch, you are also going to ack it in the same email in most cases; this seems a little weird to me, I just assumed signed-off-by could apply acked-by, but I guess not?
They are separate things. I still don't see the point of having the acked-by in the commit message; we don't need to track this for a legal or similar reason, it's really easy to get wrong or forget (the committer has to do it as the last step before commit, there is no review possibility), and for the typical use of this tag ("who approved this patch?") you want to see the whole email thread anyway. It also doesn't say "this patch was correctly reviewed": a) the committer puts in the acked-by lines himself; b) whoever committed it implicitly acked the patch. The only case where this doesn't hold is if you don't trust the people who have commit access to the repo (to a certain level at least), and then you're hosed anyway ;-)