Whats missing in http://www.linuxbios.org/Development_Guidelines?
The doc should be in the repo itself.
OK, I'll send a patch soon.
Other than that, it could be formalised a bit ;-)
Do you have a patch or specific suggestions for improvements?
Nope, I can't say I'm good at writing pseudo-legalese myself.
I'm not saying the review process is useless; I'm saying that recording history of who thought what patch was a good idea, _when those patches never end up being committed_, is pretty damn useless. A newer version of the patch superseded the old one; knowing who approved the final commit *can* of course be useful. I wasn't commenting on the review process at all; just on the acked-by lines that people add to commit messages.
OK, how about this procedure (I don't really care anymore whether it's compatible with the way it works in Linux, it should only be legally "bullet-proof"):
Everyone who creates or modifies a patch adds his Signed-off-by.
The person who finally commits the patch adds his/her Signed-off-by, too (if it's not already there anyway).
In the Linux logs, there's also an "Author:" field next to the patch subjects and date; normally it's automatically picked up from the "From:" line on the email patch (or from an explicit "From:" line in the patch). LinuxBIOS might want to have this author information more explicit, too (yes almost always the author is the same as the first signed-off-by, but there can be multiple authors for a patch, or the sign-off is done by someone else than the author, someone from the same company for example).
- The Acked-by is completely separated from that.
You send an Acked-by when you think this patch can be committed. You don't have to modify a patch for an Acked-by, you can just send it to say "I think this patch is ok".
- If a certain version of a patch received two Acked-by's by two different people, it can be committed. Ergo, every commit message will have 1 or more Signed-off-by lines
which build a "chain of trust" for legal reasons, _and_ it will have 2 or more Acked-by lines which enforce our review process.
- The Acked-by's must be for exactly the same version of the patch. Acked-by's for previous versions of the patch are meaningless, they are not added to the commit message, only those for the exact incarnation of the patch which gets committed.
Sounds all fine to me.
So yes, it is possible to post
- A patch with only a Sign-off-by: You modified the code, but don't want it to be committed, yet.
You better state that "it's not ready yet" explicitly too in such a case, to avoid confusion.
- A patch with a Signed-off-by and an Acked-by: You modified the patch and you think it can be commited.
That's the normal case. I think ack'ing your own patches is pretty meaningless (you cannot really review your own patches) but maybe that's just me.
- An email with just an Acked-by: You didn't touch the patch at all, but you think it can be
If your ACK is the last needed one, you can just go ahead and commit the patch and send an email stating you did that. The eventual committer has to type in the acked-by lines anyway.
Just one about process: it is good practice to keep the signed-off-by in the patch itself, so you won't mess-em up. Patch maintenance tools like quilt can help here.